Re: Uso system de CPU

From: Miguel Angel Hernandez Moreno <miguel(dot)hdz(dot)mrn(at)gmail(dot)com>
To: Cesar Martin <cmartinp(at)gmail(dot)com>
Cc: Alejandro Carrillo <fasterzip(at)yahoo(dot)es>, Armando Venegas Pérez <venegasp_armando(at)hotmail(dot)com>, "pgsql-es-ayuda(at)postgresql(dot)org" <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: Uso system de CPU
Date: 2012-09-10 21:11:57
Message-ID: CAGYOd3pS4mhLGhzjXLOM9PovT8M=GEqn1JrFkj3iXYTPCJ99gw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

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

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Harold Alexander Onore Harold 2012-09-10 23:34:34 Vacunn
Previous Message Cesar Martin 2012-09-10 21:05:48 Re: Uso system de CPU