Tuve problemas con enviar esta respuesta. Si llega más de una vez, disculpen.
> -----Mensaje original----- > De: [email protected] > > Buen dia Lista. > > Agredeceria una ayuda con un link o un documento que me sirva para > realizar ajustas en parametros a una > > base de datos con un promedio de 65 usuarios o mas, la confiuracion es > 12 GB de RAM , 4 Procesadores > > Ssistema Operativo Gnu/Linux RedHat Enterprise 4.0 para 32 bits > corriendo sobre unaMaquina Virutla VMvare, > > (Servidor Dell. Rack ) > > Envio el archivo de configuracion que se posee > Buen día. Tus seteos más destacados son: shared_buffers = 52458 # 420MB - Razonable work_mem = 243269 # 235MB - Irrazonable! maintenance_work_mem = 1048576 # 1GB effective_cache_size = 250000 # 2GB Si estos seteos fueron hechos a conciencia deduzco que dedicaste no más de 4GB para tu máquina virtual c/ Postgres. O tenés la limitación efectiva del redireccionamiento de 32 bits. El work_mem puede ser un problema grave. ¿Cuanta memoria te queda disponible cuando están tus 65 usuarios a toda marcha? Reduce este valor a 4096 o incluso menos si consumes mucha memoria. maintenance_work_mem también parece excesivo para la memoria disponible. Lo bajaría a 128MB para luego monitorear que autovacuum siga desempeñandose bien. Con esos ajustes podrás incrementar effective_cache_size hasta 3GB. Veo que también hiciste este ajuste: random_page_cost = 2.5 Está bien si estimas que gran parte o al menos las tablas más utilizadas entrarán completamente en caché. Perfectamente posible si tenés una base chica (< 2.5 GB entre datos e índices) El parámetro que tendrás que aumentar es: #default_statistics_target = 10 Ya está aceptado que el default de 10 es un valor demasiado bajo. Probablemente debas subir el default a 50 o 100, y algunas columnas individuales incrementarlas aún más. Despues de modificar el valor tendrás que hacer un analyze a toda la base para que recalcule las estadísticas. Para hacer un análisis más profundo deberías ya analizar las sentencias SQL que ejecuta la base. El parámetro log_min_duration_statement es un buen punto de partida para mostrar en el log aquellas que superan cierto tiempo. Podrías empezar logueando las que demoran más de 1000ms y luego ir bajando esa cota en 200 ms e ir mejorando las consultas que aparezcan sucesivamente. > > > Tengo otro caso con la misma base de datos, hemos detectado que > eventualmente e algunas tablas se da una duplicacidad de identificador > OID, como lo he solucionado, bajo a plano el contenido de la tabla, > borror y vuelvo > > a cargar, hasra ahora eso me ha dado resultado, me preguinto es un bug > de la version PostgreSQL 8.1.11 ? > > o como podria tener una solucion definitiva, tengo planteado hacer una > respaldo global, borrar y volver a crear el cluster de la base de > datos y volver a cargar datos, pero sera definitivo? La verdad que no estoy al tanto de dicho bug. Lo que si es imperioso hagas el upgrade al menos a la versión 8.1.19 que suma muchos bugs corregidos, probablemente este que comentas. Finalmente, planificar un upgrade a la última versión (8.4.2) te brindará no solo más estabilidad sino incluso una gran mejora en performance. Saludos, Fernando. -- TIP 7: no olvides aumentar la configuración del "free space map"
