Re: Postgres Out of memory

Gracias por tu atención Alvaro

En cuanto al postgres al reiniciar la máquina del server (Solaris) y
donde se encuentra el PgAdmin (XP) el problema se soluciono. Antes de
que empezara a marcar los errores de "Out of memory" ejecutaba muchos
queries cuyo resultado eran millones de líneas, los cuales en el PgAdmin
cuando aparece el mensaje "Has exceded the maximum value (100) Do you
want to retrieve all the lines?" le decía que sí, después de 1 o 2
minutos le daba STOP junto cuando estaba trayendo la información del
disco del servidor y sólo mostraba 300 000 lineas

Así fueron muchos queries y no lo sé de cierto, pero supongo que se
quedaron atorados file handlers o no se liberaba la shared memory

En cuanto a los valores de shared buffers y work mem, las conexiones que
tengo a la base de datos son 1 ó a lo mucho 2, las cuales consultan
tablas de hasta 70 millones de registros. Los valores son para asignar
la mayor cantidad de memoria RAM a este servidor dedicado a Postgres. Si
tengo 8 gigas de RAM le doy un valor adecuado al postgres para que use 2
gigas en Work_mem y cada conexión (que sólo es una) le dedica 400 Megas

Esto es porque así (bajo pruebas se comprobó) que en algunos queries no
se crean archivos temporales de 1 giga sino que Postgres aprovecha la RAM.

Saludos

Alvaro Herrera wrote:

>On Tue, Apr 05, 2005 at 03:00:08PM -0500, Eduardo Vázquez Rodríguez wrote:
>
>Hola,
>
>
>
>>Estoy corriendo un query que creo que le está pegando mucho al
>>performance de mi servidor es una máquina Solaris con 8 Gigas de RAM y
>>al correr un query me aparece un error que dice "out of memory"
>>
>>
>
>
>
>>SELECT proceso, id_mail, to_mail, temp
>>FROM (
>> SELECT proceso, id_mail, to_mail, count (*) AS temp
>> FROM SENDMAIL2
>> GROUP BY proceso, id_mail, to_mail
>> HAVING proceso = 'Automatas'
>> ) AS TAB_TEMP
>>HAVING temp != 1
>>
>>
>
>Por que no usas un solo HAVING? O sea
>
> SELECT proceso, id_mail, to_mail, temp
> FROM (
> SELECT proceso, id_mail, to_mail, count (*) AS temp
> FROM SENDMAIL2
> GROUP BY proceso, id_mail, to_mail
> HAVING proceso = 'Automatas' AND temp <> 1
> ) AS TAB_TEMP
>
>De hecho no veo para que usas la consulta externa, y por que no pones
>"proceso" en el WHERE (de hecho si te fijas en el explain, la condicion
>se mueve dentro del seqscan de sendmail2 como si fuera una clausula
>WHERE); por que no usas mejor
>
> SELECT proceso, id_mail, to_mail
> FROM SENDMAIL2
> WHERE proceso = 'Automatas'
> GROUP BY proceso, id_mail, to_mail
> HAVING count(*) <> 1
>
>
>
>
>>QUERY PLAN
>>Subquery Scan tab_temp (cost=622577.68..622612.73 rows=2003 width=118)
>>-> HashAggregate (cost=622577.68..622592.70 rows=2003 width=110)
>> Filter: (count(*) <> 1)
>> -> Seq Scan on sendmail2 (cost=0.00..622327.31 rows=20029
>>width=110)
>> Filter: ((proceso)::text = 'Automatas'::text)
>>
>>
>
>Hum! Por favor haz "SET enable_hashagg to OFF" y luego tomas el explain
>analyze de la consulta.
>
>
>
>
>>shared_buffers = 50000
>>work_mem = 2097151
>>maintenance_work_mem = 2097151
>>
>>
>
>Cual es el razonamiento que te hizo poner esos valores en work_mem y
>maintenance_work_mem? Mas que seguro, son erroneos. Bajalos a valores
>razonables; unas decenas de megas puede ser, cuando mucho ...
>shared_buffers tambien es un poco excesivo IMHO.
>
>
>

--
If I have seen further it is by standing on the shoulders of the giants
Isaac Newton