RE: Ayudo con configuracion para rendimiento de PostgreSQL 8.1.11

Tuve problemas con enviar esta respuesta. Si llega más de una vez,
disculpen.

> -----Mensaje original-----
> De: juapabsan(at)tutopia(dot)com
>
> 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.