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 <[email protected]> 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 ([email protected] > ) > Para cambiar tu suscripción: > http://www.postgresql.org/mailpref/pgsql-es-ayuda > -- ISC Miguel Angel Hernandez Moreno
