tuning al postgres

saludos lista

e tenido el detalle con la bd de que las consultas poco a poco se van
haciendo mas lentas y
tengo que reiniciar el servicio de bd para que todo se normalice

por ahi lei que se pueden estar bloqueando las tablas con mucha
concurrencia, pero el detalle es
que son select, me gustaria saber si se puede mover algo en el conf e
postgres para manejar
mas concurrencia a las tablas

tengo
16 procesadores xenon 2.4Ghz
32 GB RAM
1 particion de 500 GB con RAID 10 para datos (tablas, bd, etc)
1 particion de 350 GB con RAID 10 para indices (todo indice se va aqui)
Poastgres 8.4 64 bits

adjunto el conf de postgres por si alguien pudiese ayudarme, de antemano
muchas
gracias

--
ISC Miguel Angel Hernandez Moreno

Excerpts from Miguel Angel Hernandez Moreno's message of mié mar 09 15:49:17 -0300 2011:
> saludos lista
>
> e tenido el detalle con la bd de que las consultas poco a poco se van
> haciendo mas lentas y
> tengo que reiniciar el servicio de bd para que todo se normalice

Creo que tu work_mem es demasiado alto. ¿Qué dicen tus gráficos de
monitoreo de memoria y CPU?

> tengo
> 16 procesadores xenon 2.4Ghz
> 32 GB RAM
> 1 particion de 500 GB con RAID 10 para datos (tablas, bd, etc)
> 1 particion de 350 GB con RAID 10 para indices (todo indice se va aqui)
> Poastgres 8.4 64 bits

Creo que poner los índices y datos en RAID10 separados no ayuda.

--
Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>

At 19:49 09/03/2011, Miguel Angel Hernandez Moreno wrote:

>saludos lista
>
>e tenido el detalle con la bd de que las
>consultas poco a poco se van haciendo mas lentas y
>tengo que reiniciar el servicio de bd para que todo se normalice
>
>por ahi lei que se pueden estar bloqueando las
>tablas con mucha concurrencia, pero el detalle es
>que son select, me gustaria saber si se puede
>mover algo en el conf e postgres para manejar
>mas concurrencia a las tablas
>
>tengo
>16 procesadores xenon 2.4Ghz
>32 GB RAM
>1 particion de 500 GB con RAID 10 para datos (tablas, bd, etc)
>1 particion de 350 GB con RAID 10 para indices (todo indice se va aqui)
>Poastgres 8.4 64 bits
>
>adjunto el conf de postgres por si alguien
>pudiese ayudarme, de antemano muchas
>gracias

Doy por supuesto que no usas Windows. Si lo usas,
para Postgres y su servicio, comprueba los discos
con chkdsk y defragmentalo. Este es el principal
problema de rendimiento que he visto en los S.O.
Windows. ( Te recomiendo MyDefrag, gratuito, rapido y seguro).

Algunas ideas sueltas:

Tienes el autovacuum apagado. Esto impide, ademas
de hacer limpieza de los datos viejos que ya no
sean utiles (borrados o actualizados), poder
recabar las estadisticas necesarias para que el
planificador de consultas pueda hacer bien su
trabajo. Los archivos iran ocupando cada vez en
disco con informacion inutil, haciendo que la
cache de disco pierda efectividad. Veo en el
historico que bajo el subject "Postgres con
stand-alone" describes un problema de vacuum. ¿Es el mismo servidor?

Ademas, tienes puesto fsync a off. Eso es
peligroso y se te puede corromper la bd, no ya en
caso de fallo electrico, si no en caso de un
kernel panic del sistema, un driver que no haga
bien su trabajo u ocurra un largo etc de posibilidades probables.

Tienes puestas 500 conexiones, a mi me parecen
mucha concurrencia si tienes de ese nivel de
carga media. Si no tienes ese nivel de carga, si
la media es inferior, bajalo. Cuantas menos
tengas mas rapidas iran las que se esten
ejecutando aunque tengan que esperar otras y mas
rapidamente podras servir peticiones nuevas.
Prueba a poner pgpool por delante y pon el numero
de conexiones al nivel de carga "medio".

Que tus datos quepan en 850 GB, includidos los
indices y metadatos con una maquina con 32GB de
ram me parece cuando menos raro que la cache no
haga bien su trabajo. Ademas esa distribucion de
los discos se me hace curiosa cuando menos. Suele
importar mas tener los wal en un disco sin raid de ningun tipo.

Dado que no haces mantenimiento automatico,
prueba a hacer un reindex de las tablas mas
importantes y luego un cluster de dichas tablas.

Que tipo de carga tiene la BD?

HTH

>--
>ISC Miguel Angel Hernandez Moreno

"Si Murphy es Dios, el Coyote es su profeta"

gracias por su sugerencias

tengo una duda, existe alguna formula par calcular el shared_bufer, el
work_men y el efective_cache con la
cantidad de usuarios?? y si en el archivo del kernel (/ect/sysctl,conf) no
tengo lo que es kernel.shmmax definido
que pasa con el shared_buffer??

y con respecto a

windows, no yo uso linux suse enterprice 11.2

500 conexiones son casi el de lo que se usa en la parte normal, pero si hay
momentos donde
llegamos a tener las 500

activare el autovacuum y el fsync, pero esto usa escritura en el disco y
crei que eso podria afectar
en el perfomance

El 10 de marzo de 2011 10:45, Eduardo <nec556(at)retena(dot)com> escribió:

> At 19:49 09/03/2011, Miguel Angel Hernandez Moreno wrote:
>
> saludos lista
>>
>> e tenido el detalle con la bd de que las consultas poco a poco se van
>> haciendo mas lentas y
>> tengo que reiniciar el servicio de bd para que todo se normalice
>>
>> por ahi lei que se pueden estar bloqueando las tablas con mucha
>> concurrencia, pero el detalle es
>> que son select, me gustaria saber si se puede mover algo en el conf e
>> postgres para manejar
>> mas concurrencia a las tablas
>>
>> tengo
>> 16 procesadores xenon 2.4Ghz
>> 32 GB RAM
>> 1 particion de 500 GB con RAID 10 para datos (tablas, bd, etc)
>> 1 particion de 350 GB con RAID 10 para indices (todo indice se va aqui)
>> Poastgres 8.4 64 bits
>>
>> adjunto el conf de postgres por si alguien pudiese ayudarme, de antemano
>> muchas
>> gracias
>>
>
> Doy por supuesto que no usas Windows. Si lo usas, para Postgres y su
> servicio, comprueba los discos con chkdsk y defragmentalo. Este es el
> principal problema de rendimiento que he visto en los S.O. Windows. ( Te
> recomiendo MyDefrag, gratuito, rapido y seguro).
>
> Algunas ideas sueltas:
>
> Tienes el autovacuum apagado. Esto impide, ademas de hacer limpieza de los
> datos viejos que ya no sean utiles (borrados o actualizados), poder recabar
> las estadisticas necesarias para que el planificador de consultas pueda
> hacer bien su trabajo. Los archivos iran ocupando cada vez en disco con
> informacion inutil, haciendo que la cache de disco pierda efectividad. Veo
> en el historico que bajo el subject "Postgres con stand-alone" describes un
> problema de vacuum. ¿Es el mismo servidor?
>
> Ademas, tienes puesto fsync a off. Eso es peligroso y se te puede corromper
> la bd, no ya en caso de fallo electrico, si no en caso de un kernel panic
> del sistema, un driver que no haga bien su trabajo u ocurra un largo etc de
> posibilidades probables.
>
> Tienes puestas 500 conexiones, a mi me parecen mucha concurrencia si tienes
> de ese nivel de carga media. Si no tienes ese nivel de carga, si la media es
> inferior, bajalo. Cuantas menos tengas mas rapidas iran las que se esten
> ejecutando aunque tengan que esperar otras y mas rapidamente podras servir
> peticiones nuevas. Prueba a poner pgpool por delante y pon el numero de
> conexiones al nivel de carga "medio".
>
> Que tus datos quepan en 850 GB, includidos los indices y metadatos con una
> maquina con 32GB de ram me parece cuando menos raro que la cache no haga
> bien su trabajo. Ademas esa distribucion de los discos se me hace curiosa
> cuando menos. Suele importar mas tener los wal en un disco sin raid de
> ningun tipo.
>
> Dado que no haces mantenimiento automatico, prueba a hacer un reindex de
> las tablas mas importantes y luego un cluster de dichas tablas.
>
> Que tipo de carga tiene la BD?
>
> HTH
>
> --
>>
>> ISC Miguel Angel Hernandez Moreno
>>
>
> "Si Murphy es Dios, el Coyote es su profeta"
> -
> Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org
> )
> Para cambiar tu suscripción:
> http://www.postgresql.org/mailpref/pgsql-es-ayuda
>

--
ISC Miguel Angel Hernandez Moreno

Excerpts from Miguel Angel Hernandez Moreno's message of jue mar 10 19:59:14 -0300 2011:

> 500 conexiones son casi el de lo que se usa en la parte normal, pero si hay
> momentos donde
> llegamos a tener las 500

Uh, mal, muy mal; seguramente esto explica el problema. Bajalo a un
nivel razonable (20 o 30) y usa un pooler (pgbouncer) para atender a los
500.

--
Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>