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] > > > >
