>>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]>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]> 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]>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]> 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]> >>>> *Para:* Armando Venegas Pérez <[email protected]> >>>> *CC:* "[email protected]" <[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]> 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] >>>> To: [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] >>>> >>>> >>>> >>>> >>>> -- >>>> César Martín Pérez >>>> [email protected] >>>> >>>> >>>> >>>> >> >> >> -- >> ISC Miguel Angel Hernandez Moreno >> >> > > > -- > César Martín Pérez > [email protected] > > -- ISC Miguel Angel Hernandez Moreno
