Re: Configuración Postgres...General y Autovacuum

Pedir o Dar Ayuda en postgres escribió:

> Descripción: La plataforma tiene 4 módulos (en C ) que se conectan a la BD
> en distinta medida y esta última se usa para tareas básicas..Selects,
> Inserts, Updates y Deletes sin mayor lógica...algunos IFs por ahí simples..
> pero nada de gran inteligencia. Hay dos tablas que se llevan la carga
> transaccional... La tabla más grande es de 10 Millones de
> registros (registro pequeño) y la tabla más chica que puede llegar a 0
> registros (simula el comportamiento de una cola.. no supera los 1000
> registros con harta carga). Los módulos de la plataforma toman unos archivos
> que se cargan cada 1 minuto, los procesan y los validan con la BD para las
> sentencias básicas. (En ese intervalo de 1 minuto...en 20 a 25 seg se
> procesan todos los archivos.. el resto permanece ocioso).

Es importante que esa tabla de cola se limpie (vacuum) muy
frecuentemente, de manera que el espacio ocupado por las filas que se
van borrando pueda ser usando lo antes posible por nuevas filas.
Seguramente un vacuum cada un minuto sería apropiado.

Respecto a la tabla grande, no tengo claro qué tantos update/delete haya
en ella.

> Los módulos, el Motor psql y la BD se encuentran en el mismo
> server..... en unos meses más se tendrá el server en cluster y con una
> unidad de storage aparte para la BD..pero ese es otro cuento..

Ojo, no necesariamente va a mejorar el rendimiento con un SAN ... en la
empresa tenemos historias de clientes que reemplazaron un SAN de 1
millon de dolares (!!!) con un storage de discos enchufados
directamente, de cien mil o doscientos mil dolares, y se obtuvo mejor
rendimiento.

> Desempeño actual: Lo general es que la plataforma a simple vista anda de
> maravillas pero una vez a la semana (hasta ahora) el cliente reporta que se
> le empiezan a encolar los archivos por un momento....no le causa problemas,
> pero si le inquieta el porque podría estar sucediendo...... yo he notado
> esto en ciertas ejecuciones del autovacuum...pero muy esporádicamente ...
> por lo general el autovacuum se ejecuta muy rápidamente...
> pero ocasionalmente le ha toma de 5 a 10 minutos.....(no existe coincidencia
> de otro proceso en ejecución cuando esto ocurre..)..

Posiblemente las veces que termina rápido es porque procesa solamente la
tabla chica, y cuando se demora más es cuando procesa la tabla grande
:-)

> No se interpretar estos valores..por ejemplo la columna SHR .. hay 3
> procesos postmaster que en esta columna tienen un valor de 1,5Gb (relacion
> con shared_buffers??).... y de esos 3 procesos 1 de ellos tiene un leve uso
> de CPU... mientras que el que tiene un 17% de CPU sólo tiene 93M en esa
> columna.... ese tipo de cosas necesito entenderlas.

SHR es shared, y claro, tiene mucho que ver con shared_buffers. Tengo
entendido que top reporta la cantidad de memoria compartida que cada
proceso ha "tocado". O sea si tienes 1.5 GB de shared_buffers, un
proceso postgres que no haya hecho nada inicialmente va a reportar un
valor de SHR muy bajo; a medida que las consultas van requiriendo acceso
a la memoria, va subiendo, hasta llegar un máximo en que han accedido a
toda la memoria compartida y reportan el total. Como es memoria
compartida, no se suman entre todos los procesos. Si apretas la "c" en
top (al menos el que yo conozco) va a cambiar la ultima columna.
Algunos procesos viven mucho rato, por ej. el bgwriter; normalmente esos
procesos reportan que han tocado toda la memoria (pero no usan mucha CPU
porque su trabajo es simple). Los backends normales que se conectan,
ejecutan un par de consultas y terminan no necesariamente tocan mucha
memoria pero pueden ocupar mucha CPU.

> AYUDA: Bueno, con toda esta información acudo a Uds. para que me indiquen
> o me pregunten mas detalles... quiero saber que opinan Uds. de la
> configuración actual, que podría cambiar o que esta de más o
> sobredimensionado... no sé... soy novato.. No sé si a nivel de S.O. haya que
> modificar la asignación de memoria para optimizar su uso en conjunto con lo
> que hay en postgres..... hay algunos parámetros que me parecen altos como
> work_mem... pero tampoco estoy seguro al respecto....

work_mem no debe ser excesivamente alto porque es un valor que se usa
por cada proceso; consultas complejas pueden tener más de un sort y por
lo tanto usar más de un work_mem. Lo más importante es que no debes ver
un proceso haciendo swap, porque eso lo hace todo mucho más lento.
Debes equilibrar un shared_buffers grande con un work_mem que sea
lo más alto posible pero sin llegar a causar que se vaya a swap.

Otra cosa es tener un ojo en cómo se comporta %iowait en tu servidor.
Si es muy alto, es posible que estés corto en ancho de banda de disco
(pero esto asume que has optimizado las consultas para que usen índices
donde sea posible, y que los planes de ejecución son buenos).

> Ahhh, lo otro.....
> necesito de la paciencia de alguno de Uds. para que pueda explicarme el uso
> de los parámetros asociados al autovacuum y que actualmente tengo
> comentados... quiero optimizar el uso de esta funcionalidad.. pero no se
> cómo... he leído la documentación pero no me queda muy claro el uso de cada
> uno..

Edwin Quijada preguntaba lo mismo hace unos días .. creo que voy a
responder aparte esto. Quizás debería escribir un artículo en la wiki
que explique todo este tema, porque es largo.

--
Alvaro Herrera http://www.flickr.com/photos/alvherre/
"Uno puede defenderse de los ataques; contra los elogios se esta indefenso"