Re: [pgsql-es-ayuda] Configuración Postgres...General y Autovacuum

Hola

Gracias Alvaro por tu respuesta.... hoy no tuve tiempo para ver el foro
temprano...asi que mañana (Jueves) voy a reunir algunos datos para
graficarte la "carga - actividad" que tiene la BD y hacerte mis últimos
comentarios.

Saludos
Andrés
El 26 de agosto de 2009 11:04, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>escribió:

> 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"
>