RE: Optimizando consultas

> ________________________________
> De: Gabriel Ferro <gabrielrferro(at)yahoo(dot)com(dot)ar>
> Para: pgsql-es-ayuda(at)postgresql(dot)org
> Enviado: martes 26 de mayo de 2009, 9:29:26
> Asunto: [pgsql-es-ayuda] Optimizando consultas
>
>
> tratando de optimizar el update del otro hilo, me puse a ver
> la configuracion de postgres y despues de mucho googlear
> estoy mas perdido que antes, no he encontrado una forma para
> determinar los paramertros, lo que lei o se limita a decir
> para que sirve o muestra configuraciones para servidores
> grandes, yo tengo un AMD Athlon X2 3800+ y 1Gb RAM, las
> base de datos son muy grandes (tablas con 30millones de
> registros), las consultas se basan en busquedas con tsearch,
> actualizaciones son casi nulas.
>
> la configuracion la tengo asi
> max_conections=50
> shared_buffers =128MB
> max_fsm_pages =732992
> fsync=on
> autovacuum =off
>
> el resto comentado
>
> ________________________________
> En realidad no me soporto esa configuracion
>
> tuve que bajarle shared_buffers=24MB
> y subir a max_fsm_pages a 80000 porque el vacum me aconsejaba 79mil
>
> pero aun asi no se si esta correcto.
> ¿consejos?
>
>

Gabriel,

El update no va a mejorar con esos seteos. Está restringido por la capacidad
de tu sistema de I/O. Si querés que el update sea más rápido:
- desactiva fsync temporalmente sólo para el update (y sólo si no se hará
otra cosa en la base)
- agregá más discos en RAID 10. Son baratos y cualquier PC de hoy te soporta
4 discos, incluso 6.
- adquirí una controladora con BBU caché (mismo efecto que desactivar fsync
pero sin correr riesgo de integridad de la base). Lamentablemente son caras,
equivalente a 10 o más discos SATA.

También el update será más rápido si lo haces en un único sql a que por
medio de un loop en una función. Pero nuevamente, si el cuello de botella es
exclusivamente I/O, no cambiará nada.

Ampliar los shared buffers ayudará a tus consultas. Estimo no pudiste
levantar la base porque el SO. está configurado con valores de shared memory
muy bajos. En ese caso con este comando podrás ampliar la shared memory lo
suficiente para 128 MB de shared buffers:

sysctl -w kernel.shmmax=134217728

Para que el seteo persista tras un reboot agregá la siguiente línea en
/etc/sysctl.conf:

kernel.shmmax=134217728

En cuanto al max_fsm_pages=732992, es un valor razonable para el tamaño de
tu tabla. Sólo incrementalo si vacuum empieza a reclamarlo.

Saludos,
Fernando.