From: | "Fernando Hevia" <fhevia(at)ip-tel(dot)com(dot)ar> |
---|---|
To: | <juapabsan(at)tutopia(dot)com>, "'pgsql-es-ayuda(at)postgresql(dot)org(dot)'"(at)wm(dot)hub(dot)org |
Subject: | RE: Ayudo con configuracion para rendimiento de PostgreSQL 8.1.11 |
Date: | 2010-03-02 17:31:54 |
Message-ID: | B3E5A49C68774FA3B961A71198EC6BDA@iptel.com.ar |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
> -----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.
Attachment | Content-Type | Size |
---|---|---|
winmail.dat | application/ms-tnef | 3.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Fernando Hevia | 2010-03-02 17:33:32 | RE: Ayudo con configuracion para rendimiento de PostgreSQL 8.1.11 |
Previous Message | Jesus Maria Zabaleta Franco | 2010-03-02 16:54:16 | Terremoto en Chile |