Re: Configurar Postgresql 8.1

From: "BeMoN!o" <bemonio(at)gmail(dot)com>
To: pgsql-es-ayuda <pgsql-es-ayuda(at)postgresql(dot)org>
Cc: Fernando Hevia <fhevia(at)ip-tel(dot)com(dot)ar>
Subject: Re: Configurar Postgresql 8.1
Date: 2009-03-26 21:57:18
Message-ID: fdb3fe000903261457p63f303c2u1706b6fde4a73fc7@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Gracias por responder Fernando.

comando: vmstat -n 5

El SGBD tiene 3 clientes principales, los cuales son los encargados de
insertar datos, cada segundo hay nuevos datos a insertar, (actualmente
estoy evaluando cada cuanto inserta uno y cuantas consultas realizan
para obtener datos), y existe un cliente extra que son los usuarios
del sistema, que acceden por WEB.

Las recomendaciones sobre usar el pgpool2 para habilitar un pool de
conexiones lo estoy investigando para implementarlo, ya que los 3
clientes principales estan constantemente estableciendo, insertando y
cerrando las conexiones, imagino que con el pool mejoraría en gran
medida el sistema.

una duda...
Cuando yo decía que mi archivo de configuración:
> max_connections = 200
> shared_buffers = 131072 #representa el 25% de la RAM
> work_mem = 167772 #representa 4% RAM

me recomendaron:
> el servidor es dedicado, shared_buffers puedes
> incrementarlo tranquilamente
> a 1GB (1048576).

¿qué valor debe llevar el shared_buffer para representar 1GB, 1048576
ó 131072?, ya que yo entendía que cada unidad representaba 8KB, y
bueno allí salta mi duda.

El 26/03/09, Fernando Hevia <fhevia(at)ip-tel(dot)com(dot)ar> escribió:
>
>
>> -----Mensaje original-----
>> De: BeMoN!o
>>
>>
>> Lo que si es que activé log_min_duration_statement, ahora
>> puedo ver que consultas estan tomando tiempo y evaluando como
>> mejorarlas, muchas gracias por eso, pero lo que aun no logro
>> entender es sobre el uso de la memoria virtual, por ejemplo
>> que les parece el siguiente resultado del vmstat, ¿creen que
>> la memoría virtual debería incrementarla?
>>
>>procs -----------memory---------- ---swap-- -----io---- -system--
> ----cpu----
>> r b swpd free buff cache si so bi bo in cs us sy id
> wa
>> 6 1 80 125356 2132 3131344 1 1 7 7 8 9 15 8 62
> 15
>> 2 1 80 126484 2088 3124108 0 0 31126 9 606 22857 10 3
> 68 18
>> 0 1 80 155552 2160 3170784 0 0 23849 38 634 54925 16 13
> 56 14
>> 0 1 80 128484 2356 3191896 0 0 15230 37 603 13034 4 5
> 72 19
>
> A primera vista no parece tengas un problema de performance. Las esperas de
> E/S son razonables para los inserts masivos que asumo estás haciendo. Tu
> sistema no está swapeando por lo que tampoco hay necesidad urgente de
> ajustar el uso de memoria.
> Lo que llama la atención es el alto nivel de context-switches (cs). ¿Qué
> intervalo le pasaste a vmstat para obtener esta salida? ¿Podrías describir
> qué estaba haciendo el sistema en ese momento?
>
> Saludos.
>
>
>
>
>
>
>
>
>>
>>
>> El 17 de marzo de 2009 15:10, Fernando Hevia
>> <fhevia(at)ip-tel(dot)com(dot)ar> escribió:
>>
>>
>>
>>
>> > -----Mensaje original-----
>> > De: BeMoN!o
>> >
>>
>> > Me gustaría obtener ayuda y documentación sobre la
>> > configuración "Tunning" del Postgresql para la versión 8.1.
>> > ya que he jugado con algunos de los valores y ha mejorado su
>> > desempeño, pero aun considero que por falta de conocimientos
>> > no es lo óptimo (si la documentación es en español mejor).
>> >
>> > características:
>> > Linux - Debian kernel 2.6.18.
>> > 2 procesadores Dual Core 3.4, 4GB, 1.5Gb de Swap.
>> >
>> > max_connections = 200
>> > shared_buffers = 131072 #representa el 25% de la RAM
>> > work_mem = 167772 #representa 4% RAM
>> >
>>
>>
>> Pareciera tenés un error en la interpretación de shared
>> buffers. El valor
>> asignado no se corresponde con el porcentaje de memoria
>> que aduces. Dado que
>> el servidor es dedicado, shared_buffers puedes
>> incrementarlo tranquilamente
>> a 1GB (1048576).
>>
>> Revisa work_mem porque lo tienes en 167 MB. No es que
>> esté mal, pero es un
>> valor atípicamente alto y si tienes muchas conexiones
>> paralelas es probable
>> te esté consumiendo toda la memoria (fácil de
>> corroborar con vmstat).
>> Dependiendo del tipo de consultas que se ejecuten y la
>> cantidad de
>> conexiones simultáneas sugeriría jueges con valores más
>> razonables para
>> work-mem, entre 1024 y 16384 (KB). Ten presente que
>> reducir work_mem puede
>> hacer más lentas consultas que requieran varios sorts,
>> hashs o merge joins
>> con muchos registros.
>>
>> Las recomendaciones en líneas generales suelen ser las
>> siguientes:
>>
>> 1. Identifica los cuellos de botella antes de actuar
>> (Monitorear el sistema
>> c/ vmstat, queries lentos con log_min_duration_statement)
>> 2. Asegura que autovacuum este corriendo o vacuum
>> croneado regularmente.
>> 3. Haz un tunning de los queries más problemáticos
>> 4. Habilita un pool de conexiones (pgpool2, pgbouncer)
>> 5. Planifica el upgrade a una versión más reciente. 8.4
>> está en puerta. Las
>> nuevas versiones dan un salto importante en performance
>> sobre 8.1.
>> 6. Mejora el hardware. Los principales items donde mirar son:
>> - Agregar discos y migrar a RAID 10.
>> - Agregar una controladora con BBU caché
>> - Agregar más memoria.
>>
>>
>> Saludos,
>> Fernando.
>>
>>
>>
>>
>>
>>
>>
>> --
>> BeMoN!o.
>>
>>
>
>

--
BeMoN!o.

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Santiago Zarate 2009-03-26 22:02:04 Re: Active Record
Previous Message dali aparicio 2009-03-26 21:56:07 Re: Active Record