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 <alvhe...@alvh.no-ip.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" >
