Re: Uso system de CPU

>>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 <cmartinp(at)gmail(dot)com>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 <
> miguel(dot)hdz(dot)mrn(at)gmail(dot)com> 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 <cmartinp(at)gmail(dot)com>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" <fasterzip(at)yahoo(dot)es> 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 <cmartinp(at)gmail(dot)com>
>>>> *Para:* Armando Venegas Pérez <venegasp_armando(at)hotmail(dot)com>
>>>> *CC:* "pgsql-es-ayuda(at)postgresql(dot)org" <pgsql-es-ayuda(at)postgresql(dot)org>
>>>> *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 <
>>>> venegasp_armando(at)hotmail(dot)com> 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: cmartinp(at)gmail(dot)com
>>>> To: pgsql-es-ayuda(at)postgresql(dot)org
>>>>
>>>>
>>>> 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
>>>> cmartinp(at)gmail(dot)com
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> César Martín Pérez
>>>> cmartinp(at)gmail(dot)com
>>>>
>>>>
>>>>
>>>>
>>
>>
>> --
>> ISC Miguel Angel Hernandez Moreno
>>
>>
>
>
> --
> César Martín Pérez
> cmartinp(at)gmail(dot)com
>
>

--
ISC Miguel Angel Hernandez Moreno