Re: tuning al postgres

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