RE: Update lentos

> -----Mensaje original-----
> De: Miguel Angel Hernandez Moreno
>
> Disculpen e tenido un problema algo interesante, tengo tablas
> con millones de registros y hago select muy complejos pero la
> verdad es que el problema no son los SELECT por que los
> Select lo efectua en "ms" y por ejemplo hago los updates y 3
> updatese tardan 1 segundo, y para mi caso es un problema muy
> fuerte ya que hago updates de forma muy seguida!!
>
>
> y ofresco un fragmento de mi conf de postgres ya que es lo
> unico que e modificado todo lo demas queda por defecto, yo
> manejo SLE 11 con Postgres 8.4.3 en server Blade de DELL, si
> alguien sabe por que tardan tanto los update y en caso
> contrario los select son muy pero muy rapidos!!

Los selects son muy rápidos porque la información es leída del caché en RAM.
En cambio, los updates en una base ACID como Postgres requieren una serie de
operaciones sobre el disco que son mucho más lentas (algo así como un read
tupla vieja, write wal, write tupla nueva, write tupla vieja).

>
> shared_buffers = 2GB # min 128kB
> #temp_buffers = 8MB # min 800kB
> #max_prepared_transactions = 0 # zero disables the feature
> work_mem = 1GB # min 64kB
> maintenance_work_mem = 1GB
> effective_cache_size = 21GB
>

Como dijo Jaime, work_mem es excesivo más si tienes hasta 1000 conexiones
simultáneas. Que por cierto esa cantidad de conexiones es otra barbaridad.
Considera implementar un pool de conexiones con pgbouncer o pgpool2 y limita
las conexiones a la base a 40-60 para tu escenario.

Yendo al problema de los inserts lentos, los cuellos de botella en inserts
es un tema delicado. Algunas de las sugerencias generales que caben son:
- ¿Es ocasional la congestión en los inserts? En tal caso verifica que no
coincida con los checkpoints (log_checkpoints = on para ver su actividad en
el log). Incrementa checkpoints_segments empezando en 10 e incrementando de
5 en 5 progresivamente y mide el resultado.
- configura para que vacuum trabaje seguido sobre esta tabla (quizá cada 4-5
min, incluso menos). Vacuum a secas, nada de vacuum full!!
- si los checkpoints son un problema reduce shared_buffers y deja que el
caché lo provea el S.O. Prueba bajando a 256 MB o menos, incluso hasta 32MB
en caso de sistemas con inserts masivos en forma sostenida.
- ¿que sistema de discos tienes? Para performance hay que ir por RAID 10 y
evitar RAID 5 por completo, cuantos más discos mejor.
- considera comprar una controladora con caché para las escrituras. Este
buffer absorverá el seek-time para el posicionamiento de los cabezales en la
escritura.
- deshabilita synchronous_commit si puedes permitirte perder algunas
transacciones en caso de un crash.
- trata de hacer múltiples updates en una misma transacción de ser posible.
Posiblemente implementando un buffer en archivo plano que será procesado
periódicamente por un proceso independiente que ejecute los updates.
- elimina los índices sobre los campos actualizados que no sean
absolutamente necesarios.
- si el registro es muy grande (recuerda que Postgres escribirá una copia
completa de la tupla actualizada) posiblemente convenga separar los campos
actualizables a una tabla aparte.

Hasta ahí lo que se me ocurre ahora.

Saludos,
Fernando.