2.3, pero también lo descarte de la causa, porque con pgpool apagado y el Doctrine conectando directo a la BBDD seguía pasando lo mismo.
El 11 de septiembre de 2012 17:47, Lazáro Rubén García Martínez < [email protected]> escribió: > 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 > -- César Martín Pérez [email protected]
