Re: Uso system de CPU

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 <
lgarciam(at)vnz(dot)uci(dot)cu> escribió:

> Que versión de Pgpool estas usando?
>
> Saludos.
> ________________________________________
> From: pgsql-es-ayuda-owner(at)postgresql(dot)org [
> pgsql-es-ayuda-owner(at)postgresql(dot)org] On Behalf Of Cesar Martin [
> cmartinp(at)gmail(dot)com]
> Sent: Tuesday, September 11, 2012 10:35 AM
> To: Miguel Angel Hernandez Moreno
> Cc: Alejandro Carrillo; Armando Venegas Pérez;
> pgsql-es-ayuda(at)postgresql(dot)org
> 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 <
> miguel(dot)hdz(dot)mrn(at)gmail(dot)com<mailto:miguel(dot)hdz(dot)mrn(at)gmail(dot)com>> 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 <cmartinp(at)gmail(dot)com
> <mailto: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<mailto: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
> <mailto: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<mailto:
> 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<mailto:cmartinp(at)gmail(dot)com>>
> Para: Armando Venegas Pérez <venegasp_armando(at)hotmail(dot)com<mailto:
> venegasp_armando(at)hotmail(dot)com>>
> CC: "pgsql-es-ayuda(at)postgresql(dot)org<mailto:pgsql-es-ayuda(at)postgresql(dot)org>"
> <pgsql-es-ayuda(at)postgresql(dot)org<mailto: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<mailto: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<mailto:cmartinp(at)gmail(dot)com>
> To: pgsql-es-ayuda(at)postgresql(dot)org<mailto: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<mailto:cmartinp(at)gmail(dot)com>
>
>
>
>
> --
> César Martín Pérez
> cmartinp(at)gmail(dot)com<mailto:cmartinp(at)gmail(dot)com>
>
>
>
>
>
>
> --
> ISC Miguel Angel Hernandez Moreno
>
>
>
>
> --
> César Martín Pérez
> cmartinp(at)gmail(dot)com<mailto:cmartinp(at)gmail(dot)com>
>
>
>
>
> --
> ISC Miguel Angel Hernandez Moreno
>
>
>
>
> --
> César Martín Pérez
> cmartinp(at)gmail(dot)com<mailto:cmartinp(at)gmail(dot)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
>
> 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
cmartinp(at)gmail(dot)com