[pgsql-es-ayuda] Uso system de CPU

[Cesar Martin]

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
cmart...@gmail.com

RE: [pgsql-es-ayuda] Problema con Zona horaria

[Edwin Quijada]

> From: ja...@2ndquadrant.com
> Date: Sun, 9 Sep 2012 16:01:45 -0500
> Subject: Re: [pgsql-es-ayuda] Problema con Zona horaria
> To: listas_quij...@hotmail.com
> CC: pgsql-es-ayuda@postgresql.org
> 
> 2012/9/7 Edwin Quijada :
> > Hola!
> > He desarrollado una aplicacion que corrreta en varios POS, 234, los cuales
> > se encuentran en mi pais. La base de datos se encuentra en un servidor en la
> > nube el cual se encuentra en pacifico zona horaria, yo estoy en republica
> > Dominicana la cual tiene zona horaria, Caracas/La Paz, estoy a 3 horas de
> > diferencia. Quiero saber como debo configurar a PG para que siempre almacene
> > las horas y fechas de acuerdo a mi zona horaria y no a esa zona horaria
> > donde se encuentra.
> >
> > Otra cosa, en mi pais no hay cambio de horario por temporara por lo que en
> > un momento la diferencia es de 4 horas y no 3
> >
> 
> Ok. Hay una pequeña discrepancia entre caracas y la paz, parece que la
> paz es GMT-4 y La Paz GMT-4:30.
> 
> Republica Dominaca esta en GMT-4 asi que America/Caracas parece ser
> mas preciso para ti.
> 
> Ahora, tambien podrías poner GMT-4 o:
> """
> postgres=# select * from pg_timezone_names where name ilike '%domin%';
> name | abbrev | utc_offset | is_dst
> -+++
>  posix/America/Dominica  | AST| -04:00:00  | f
>  posix/America/Santo_Domingo | AST| -04:00:00  | f
>  America/Dominica| AST| -04:00:00  | f
>  America/Santo_Domingo   | AST| -04:00:00  | f
> """

Jaime, lo que no se es como ponerle la hora a mi server para que sea la mia. 
Porque no tengo acceso a cambiar nada en el servidor ya que es un host entonces 
queria hacerlo via PostgreSQL.Puedo definirle a PG en que zona horaria debe de 
trabajar?La mia es -4 Santo_Domingo
  

RE: [pgsql-es-ayuda] Problema con Zona horaria

[Alvaro Herrera]

Excerpts from Edwin Quijada's message of lun sep 10 09:35:37 -0300 2012:

> Jaime, lo que no se es como ponerle la hora a mi server para que sea
> la mia. Porque no tengo acceso a cambiar nada en el servidor ya que es
> un host entonces queria hacerlo via PostgreSQL.Puedo definirle a PG en
> que zona horaria debe de trabajar?La mia es -4 Santo_Domingo

Quizás deberías cambiar la opción TimeZone en postgresql.conf.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

[pgsql-es-ayuda] Liberada la versión 9.2

[Cesar Erices]

http://www.postgresql.org/about/press/presskit92/es/

-- 
Sin más que decir se despide de Usted, muy atentamente

Cesar Erices Vergara
Ingeniero en Gestión Informática
Analista de Sistema

Santiago - Chile

Re: [pgsql-es-ayuda] Problema con Zona horaria

[zahory]

Esta forma esta mucho mejor.

--Mensaje original--
De: Alvaro Herrera
Para: Hector R De los Santos
Asunto: Re: [pgsql-es-ayuda] Problema con Zona horaria
Enviado: 10 de sep, 2012 10:16 AM

Excerpts from Hector R. De los Santos's message of lun sep 10 11:06:18 -0300 
2012:
> Alvaro, el problema es que el no tiene acceso a esos archivos, esta en un
> servidor remoto donde al parecer no puede modificar la configuracion de PG.

Entonces
ALTER DATABASE ... SET TimeZone = 'America/Santo_Domingo'
de manera que se ponga automáticamente en cada nueva conexión a esa BD.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


Enviado desde mi dispositivo BlackBerry® de Claro Dominicana-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

RE: [pgsql-es-ayuda] Uso system de CPU

[Armando Venegas Pérez]

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: cmart...@gmail.com
To: pgsql-es-ayuda@postgresql.org

Buenos días,
Tengo un servidor postgres 8.3 con la siguiente configuración HW:
128GB de RAM2 procesadores AMD Opteron 6282 con 16 cores cada uno2 
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 = offwal_buffers = 8MB   
checkpoint_segments = 32

checkpoint_completion_target = 0.9  effective_cache_size = 
100GBconstraint_exclusion = onmax_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
cmart...@gmail.com


  

RE: [pgsql-es-ayuda] Problema con Zona horaria

[Edwin Quijada]

Esto era lo que necesitaba.Gracias,Alvaro.!

> Subject: Re: [pgsql-es-ayuda] Problema con Zona horaria
> To: alvhe...@2ndquadrant.com; pgsql-es-ayuda@postgresql.org
> From: zah...@gmail.com
> Date: Mon, 10 Sep 2012 14:42:15 +
> 
> Esta forma esta mucho mejor.
> 
> --Mensaje original--
> De: Alvaro Herrera
> Para: Hector R De los Santos
> Asunto: Re: [pgsql-es-ayuda] Problema con Zona horaria
> Enviado: 10 de sep, 2012 10:16 AM
> 
> Excerpts from Hector R. De los Santos's message of lun sep 10 11:06:18 -0300 
> 2012:
> > Alvaro, el problema es que el no tiene acceso a esos archivos, esta en un
> > servidor remoto donde al parecer no puede modificar la configuracion de PG.
> 
> Entonces
> ALTER DATABASE ... SET TimeZone = 'America/Santo_Domingo'
> de manera que se ponga automáticamente en cada nueva conexión a esa BD.
> 
> -- 
> Álvaro Herrerahttp://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
> 
> 
> Enviado desde mi dispositivo BlackBerry® de Claro Dominicana-
> Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
> Para cambiar tu suscripción:
> http://www.postgresql.org/mailpref/pgsql-es-ayuda
  

Re: [pgsql-es-ayuda] Uso system de CPU

[Cesar Martin]

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_arma...@hotmail.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: cmart...@gmail.com
> To: pgsql-es-ayuda@postgresql.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
> cmart...@gmail.com
>
>


-- 
César Martín Pérez
cmart...@gmail.com

Re: [pgsql-es-ayuda] Uso system de CPU

[Alejandro Carrillo]

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 
>Para: Armando Venegas Pérez  
>CC: "pgsql-es-ayuda@postgresql.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 
> 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: cmart...@gmail.com
>>To: pgsql-es-ayuda@postgresql.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
>>cmart...@gmail.com
>>
>>
>
>
>
>-- 
>César Martín Pérez
>cmart...@gmail.com
>
>
>
>

[pgsql-es-ayuda] COPY

[Guillermo Villanueva]

Hola amigos , cómo están?
porque puede ser que
copy mensajes to '/tmp/mensajes15.csv' (format 'csv')
No esté poniendo el quote comillas en las cadenas, ni siquiera cuando lo
hago así:
copy mensajes to '/tmp/mensajes15.csv' (format 'csv', QUOTE '"', DELIMITER
';')
Espero sus comentarios y muchas gracias desde ya.
Saludos
Guillermo Villanueva

RE: [pgsql-es-ayuda] Postgres lento ¿effective_cache_size?

[Lazáro Rubén García Martínez]

Debes configurar de esta forma:

effective_cache_size = ( AvRAM * 0.75 )

effective_cache_size = ( 4096 * 0.75 ) MB

Saludos.

From: pgsql-es-ayuda-ow...@postgresql.org [pgsql-es-ayuda-ow...@postgresql.org] 
On Behalf Of Jose Mercedes Venegas Acevedo [jvenegasp...@gmail.com]
Sent: Monday, September 10, 2012 12:47 PM
To: pgsql-es-ayuda@postgresql.org
Subject: [pgsql-es-ayuda] Postgres lento ¿effective_cache_size?

Buenos dia a todos tengo este problema

tengo un servidor de 3.0 Ghz y 4 Gb de RAM

en el tengo instalado postgres y ms4w que es un entorno para mostrar mapas con 
mapserver

mi configuracion de postgres los valores que he tocado son estos

shared_buffers =  512MB
work_mem = 2MB
effective_cache_size = 256MB

el asunto es que en la mañana cuando recien empiezo a trabajar y uso esta 
aplicacion para buscar sobre goemtrias generalmente calles
y tengo inserciones a medio dia aproximadamente se pone lento.

estuve leyendo que efective cache un valor bajo favorece las busquedas 
secuencias y un valor alto el uso de indices?
mi pregunta es un valor alto se referiria a que debo colocar en effective cache 
size un valor superior a shared buffers o no tiene nada que ver cuanto mas 
podria aumentarle a estos valores para mejorar mis busquedas.

PD solo tengo alrededor de 70 usuarios y el max conections es 100

saludos

--
José Mercedes Venegas Acevedo
cel: Mov. 949808846

mails: jvenegasp...@php.net
  jvenegasp...@gmail.com

PHP Spanish Docs translator member.
http://www.php.net/manual/es/index.php



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

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda

Re: [pgsql-es-ayuda] Uso system de CPU

[Cesar Martin]

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"  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 
> *Para:* Armando Venegas Pérez 
> *CC:* "pgsql-es-ayuda@postgresql.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_arma...@hotmail.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: cmart...@gmail.com
> To: pgsql-es-ayuda@postgresql.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
> cmart...@gmail.com
>
>
>
>
> --
> César Martín Pérez
> cmart...@gmail.com
>
>
>
>

Re: [pgsql-es-ayuda] Uso system de CPU

[Miguel Angel Hernandez Moreno]

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 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"  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 
>> *Para:* Armando Venegas Pérez 
>> *CC:* "pgsql-es-ayuda@postgresql.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_arma...@hotmail.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: cmart...@gmail.com
>> To: pgsql-es-ayuda@postgresql.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 

[pgsql-es-ayuda] Vacunn

[Harold Alexander Onore Harold]

Saludos Comunidad,


Ando en la busqueda de algun script para realizar los vacunn de manera
periodica  ? alguien tiene alguno a la mano


Atentamente,


Harold Onore

Re: [pgsql-es-ayuda] Postgres lento ¿effective_cache_size?

[Alvaro Herrera]

Excerpts from Jose Mercedes Venegas Acevedo's message of lun sep 10 14:17:26 
-0300 2012:
> Buenos dia a todos tengo este problema
> 
> tengo un servidor de 3.0 Ghz y 4 Gb de RAM

> PD solo tengo alrededor de 70 usuarios y el max conections es 100

La RAM es barata.  Compra más, instálala y sin tocar ninguna
configuración debería andar mucho mejor.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda