Que versión de Pgpool estas usando? Saludos. ________________________________________ From: [email protected] [[email protected]] On Behalf Of Cesar Martin [[email protected]] Sent: Tuesday, September 11, 2012 10:35 AM To: Miguel Angel Hernandez Moreno Cc: Alejandro Carrillo; Armando Venegas Pérez; [email protected] Subject: Re: [pgsql-es-ayuda] Uso system de CPU
Me ha gustado la idea del NOW-query_start, es bastante practica. La consulta que yo suelo ejecutar en este caso es: select query_start,procpid,current_query from pg_stat_activity where current_query != '<IDLE>' order by query_start; Que en esencia viene a ser lo mismo, lo único que quito los "IDLE" ya que al estar conectado a PgPool te deja conexiones establecidas. Cuando digo normales, me refiero a que no había DELETE o UPDATE que me pudieran estar bloqueando un tabla, ni tampoco SELECT que hicieran búsquedas secuenciales brutales... Eso si, consultas que tardaran habia, porque cuando el servidor se ponia en este estado, hasta un select * de una tabla de 100 segistros, podia tardar varios segundos en salir. Lo que me sigue sin cuadrar, es que reiniciara la BBDD, y no sirviera de la nada y sin embargo parece que el reinicio de la maquina ha solucionado un problema que estuvo ocurriendo de forma intermitente durante tres semanas. El 11 de septiembre de 2012 16:35, Miguel Angel Hernandez Moreno <[email protected]<mailto:[email protected]>> escribió: >>Cuando se bloqueaba, analizamos las consultas del pg_stat_activity, pero eran >>todas normales. define normal select NOW()-query_start as tiempo, * from pg_stat_activity fijate si ahi no tienes alguna consulta que lleve mucho tiempo, esto te puede ayudar El 11 de septiembre de 2012 04:37, Cesar Martin <[email protected]<mailto:[email protected]>> escribió: Buenas Miguel Angel, A la BBDD le hago un vaccum verbose analyze todos los dias y todos los mensajes son del tipo: INFO: <AB>dossier<BB>: se procesaron 924 de 924 p<E1>ginas, que conten<ED>an 74652 filas vigentes y 0 filas no vigentes; 3000 filas en la muestra, 74652 total de filas estimadas Entiendo que al haber 0 filas no vigentes, no es necesario correr el full vacuum, es correcto? Cuando se bloqueaba, analizamos las consultas del pg_stat_activity, pero eran todas normales. A mi lo que me sigue sin cuadrar, es que cuando postgres ocupa la CPU, el tipo de carga es user, no system... Otra cosa que tambien he comprobado, es que sin estar en el momento critico con todas las cpu al 100%, la BBDD da timeouts a la hora de conectarse a ella, cuando deberia tener conexiones de sobra, ya que tengo un munin2 puesto y en ningun caso las conexiones suben de 200. Un saludo El 10 de septiembre de 2012 23:11, Miguel Angel Hernandez Moreno <[email protected]<mailto:[email protected]>> escribió: saludos podrias hacerle un analyze verbose (con esto veras que puede ser como te comenta alejandro que un vacuum full sea lo que te hace falta o un vacuum) >>Pero vacuum full por Lo que yo tenía entendido, sólo recupera espacio en disco Pues si, te recupera las paginas en blanco pero en si hace mas rapida la busqueda Al igual que puedes ver las stadisticas de la bd cuando la tengas "lenta" has un select * from pg_stat_activity Esto te dira que proceso esta ejecutandose, puede ser que tu bd se haga lenta por consultas que se quedan colgadas, ya sea por mal diseño, por falta de indices, por bloqueo de tabla o por falta de mantenimiento. Lo que sea esta consulta te dira lo que esta haciendo tu postgres cuando anda lento y ahi si peudes porfa nos comentas. gracias y espero te pueda servir El 10 de septiembre de 2012 16:05, Cesar Martin <[email protected]<mailto:[email protected]>> escribió: Pero vacuum full por Lo que yo tenía entendido, sólo recupera espacio en disco y si hay una politica de vacuums diarios, como es mi caso, creía que no sólo no era necesario, sino poco recomendable. De todas formas es extraño porque los 32 cores de la máquina, se ponen con carga 100% system. Porque una falta de vacuum full puede provocar algo asi? Gracias! El 10/09/2012 18:56, "Alejandro Carrillo" <[email protected]<mailto:[email protected]>> escribió: Podria ser el vacuum full faltante en algunas tablas: "Ademas en otros casos cuando ha sido provocado por una consulta, lo que subía era el acceso a disco y la carga del servidor era de tipo "IO wait" no de tipo System. " ________________________________ De: Cesar Martin <[email protected]<mailto:[email protected]>> Para: Armando Venegas Pérez <[email protected]<mailto:[email protected]>> CC: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Enviado: Lunes 10 de septiembre de 2012 11:31 Asunto: Re: [pgsql-es-ayuda] Uso system de CPU Hola Armando, gracias por tu respuesta. No, no puede ser un cron, ya que no tiene una periodicidad tan determinada. Además en el momento de subir la carga, los únicos procesos son de postgres y de echo el servidor, solo tiene postgres en exclusiva, no corre nada mas en el. Un saludo. El 10 de septiembre de 2012 16:48, Armando Venegas Pérez <[email protected]<mailto:[email protected]>> escribió: Hola Cesár. A mi me paso algo similar, pero el problema era un proceso que corría por CRON y se nos había olvidado. Tal vez no sea tu caso, pero por si las dudas. Saludos ________________________________ Date: Mon, 10 Sep 2012 11:30:41 +0200 Subject: [pgsql-es-ayuda] Uso system de CPU From: [email protected]<mailto:[email protected]> To: [email protected]<mailto:[email protected]> Buenos días, Tengo un servidor postgres 8.3 con la siguiente configuración HW: 128GB de RAM 2 procesadores AMD Opteron 6282 con 16 cores cada uno 2 controladoras Raid con 1GB de memoria h700: Raid1(sistema), Raid10 4HD(xlog) h800: Raid10 12HD (En cabina) (DB) La DB tiene actualmente unos 250GB y lleva una aplicación web que se conecta mediante un PGPool en modo Pool de conexiones. La configuracion actual de postgres es la siguiente: max_connections = 500 (aunque desde el pgpool las limito a 400) unix_socket_directory = '/var/run/postgres' shared_buffers = 12GB work_mem = 6MB maintenance_work_mem = 1GB max_fsm_pages = 8553600 max_fsm_relations = 409000 fsync = on synchronous_commit = off wal_buffers = 8MB checkpoint_segments = 32 checkpoint_completion_target = 0.9 effective_cache_size = 100GB constraint_exclusion = on max_locks_per_transaction = 100 Hace algunas semanas, la DB, de repente, empezó a ir lentísima y generar cientos de timeouts a la hora de conectar el frontal web. Las carga de trabajo de la DB era ridícula comparada con la normal (al ser el mes de Agosto) y sin embargo las queries iban muy lentas. La carga del servidor subía hasta llegar a 300 y las cpu corrían al 100% con carga tipo system o kernel, sin embargo a nivel de disco en ambos volumenes la carga de I/O no superaba las 100 IOPS. Este problema persistió durante todas las mañanas, hasta el punto de hacerme reiniciar la BBDD a diario... en un solo día llegue a reiniciarla hasta 4 veces, hasta que un día, puesto que no encontraba la solución, reinicie el servidor y parece que el problema se ha mitigado durante mas o menos unos diez días, ya que el otro día repitió el mismo patrón de comportamiento. He analizado los logs en busca de alguna query conflictiva, pero no hay ninguna que pueda provocar un bloqueo así. Ademas en otros casos cuando ha sido provocado por una consulta, lo que subía era el acceso a disco y la carga del servidor era de tipo "IO wait" no de tipo System. Los logs de sistema tampoco dan ningún error de kernel. La Swap, tampoco se esta usando, ya que el swappines del proc esta a 0. A alguien le ha pasado algo similar?? Se os ocurre que puede estar pasando?? Algún problema HW?? No duden en pedirme cualquier datos necesario. Muchas gracias de antemano, un saludo. -- César Martín Pérez [email protected]<mailto:[email protected]> -- César Martín Pérez [email protected]<mailto:[email protected]> -- ISC Miguel Angel Hernandez Moreno -- César Martín Pérez [email protected]<mailto:[email protected]> -- ISC Miguel Angel Hernandez Moreno -- César Martín Pérez [email protected]<mailto:[email protected]> ________________________________ Fin a la injusticia, LIBERTAD AHORA A NUESTROS CINCO COMPATRIOTAS QUE SE ENCUENTRAN INJUSTAMENTE EN PRISIONES DE LOS EEUU! http://www.antiterroristas.cu http://justiciaparaloscinco.wordpress.com Fin a la injusticia, LIBERTAD AHORA A NUESTROS CINCO COMPATRIOTAS QUE SE ENCUENTRAN INJUSTAMENTE EN PRISIONES DE LOS EEUU! http://www.antiterroristas.cu http://justiciaparaloscinco.wordpress.com - Enviado a la lista de correo pgsql-es-ayuda ([email protected]) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
