Skip site navigation (1) Skip section navigation (2)

RE: Bajo rendimiento en postgresql cuando se lanza un delete

From: "Fernando Hevia" <fhevia(at)ip-tel(dot)com(dot)ar>
To: "'Francisco Manuel Quintana Trujillo'" <fquintana(at)itccanarias(dot)org>,<pgsql-es-ayuda(at)postgresql(dot)org>
Subject: RE: Bajo rendimiento en postgresql cuando se lanza un delete
Date: 2009-07-30 14:31:37
Message-ID: A904E0273D4145B0A9D8C2335C4E0B67@iptel.com.ar (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
> -----Mensaje original-----
> De: Francisco Manuel Quintana Trujillo
> 
> Hola a todos,
> 
> Hace unas semanas instalé postgresql 8.3.7 en un Windows xp sp3.
> Especificaciones de la máquina, 2 Gb de Ram, 2 discos duros 
> sata de 150 Gb cada uno, procesador Pentium 4 dual core a 3.2Ghz.
> 
> Un disco duro se utiliza para el sistema operativo y las 
> aplicaciones, incluido el postgresql y el otro disco se 
> utiliza para la  base de datos la cual ocupa 105 Gb entre 
> índices y datos. Lo más destacado es que existen 2 tablas que 
> contienen 130 millones de registros cada una.
> 

Mis recomendaciones de más importante a menos importante:

1. Tratá de tener 4 discos en RAID 10. (mejor si puedes instalar más discos)
2. Si no es posible comprar más discos, configura tus 2 discos en RAID 1
3. Llevá la base a Linux o a Windows 2003 Server

> La verdad es que todo funciona de maravillas si no tenemos en 
> cuenta la fragmentación que sufre el disco en las inserciones 
> pero que se resuelve con un simple defrag. El caso es que a 
> la hora de realizar un select los tiempos de respuesta son 
> más que aceptables pero no así cuando ejecuto un delete de este tipo
> 

Se me ocurre que la fragmentación no debiera ser demasiado problemática. 
Quizá afecte algo en lecturas secuenciales sobre grandes cantidades de
datos.

> delete from observation where observation_id not in (select 
> distinct(observation_id) from quality) esto significa en 
> tiempos de cpu 72 horas y sin solución por el momento.
> 

El delete debiera ser mejorable pero tendrías que mostrarnos el resultado
del explain y estructuras de observation y quality como para poder darte
alguna sugerencia.
¿No tendrás clave foráneas? Asegurate de tener índices sobre las columnas
referenciada siempre! Sino cada registro a eliminar forzará un scan
secuencial sobre la tabla referenciada a fines de verificar se cumpla la
constraint.

> Mis preguntas son:
> 
> ¿Es normal?,
>

Digamos que normal no. Pero depende de la actividad del sistema, de cuantos
registros estás eliminando, cuantos índices se ven afectados, si hay claves
foráneas sobre la tabla afectada, etc.

> ¿puede ser un problema de bloqueos? ¿cómo puedo averiguar si 
> la consulta no progresa?
>

Estás borrando registros. Definitivamente puede ser un problema de bloqueos
si hay otros usuarios trabajando sobre los mismos.
En postgres puedes ver los lockeos con esta consulta: select * from
pg_locks;
En Windows usa perfmon.exe para monitorear la actividad del sistema y
tendrás una idea de si está trabajando o no. Para esta consulta en
particular presta atención a la carga sobre los discos.

> ¿Qué  otra solución se puede dar a la fragmentación de disco? 
> ¿se puede forzar al postgresql a reservar espacio en disco?
>

Deja este tema para lo último. Dudo que sea decisivo.

> He leído las optimizaciones  que se pueden realizar:
> 
> Separar las distintas bases de datos en discos duros 
> independientes así como sus índices, discos duros en raid, 
> realizar cluster de las tablas, por el momento no son 
> posibles. Además realizo vacuum cada 2 millones de inserciones.
> 

Un Raid 1 no puede "no ser posible". Haz el esfuercito y no lo lamentarás.

> Agradeciendo de antemano cualquier ayuda
> 
> Saludos, Oliver
> 

Saludos,
Fernando.


In response to

pgsql-es-ayuda by date

Next:From: Silvio QuadriDate: 2009-07-30 15:37:56
Subject: Re: Bajo rendimiento en postgresql cuando se lanza un delete
Previous:From: Antonio QuintanaDate: 2009-07-30 14:23:02
Subject: Re: INDICE CON "like"

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group