Discussion:
procesos ocupan el total de la RAM
felix gonzales
2011-06-28 21:05:27 UTC
Permalink
Amigos de la list@

Desde hace buen tiempo hemos notado en nuestro servidor de postgres, que el
espacio de memoria que ocupan los procesos que corremos (funciones
de inserción de datos, consultas, creación de tablas
temporales, modificaciones de datos, etc) se van acumulando en la RAM
(tenemos 43 GB) llega un momento que tanto el SWAP como la memoria
disponible se registra al 100% y no nos queda otra que reiniciar el
servicio.

Existe alguna manera de hacer que la memoria se libere de
manera automática después de correr algún proceso???

Adjunto una pantalla con el comando "top" corrido en nuestro servidor.


Gracias de antemano,


Felix Gonzales
Jaime Casanova
2011-06-28 23:08:11 UTC
Permalink
Desde hace buen tiempo hemos notado en nuestro servidor de postgres, que el espacio de memoria que ocupan los procesos que corremos (funciones
de inserción de datos, consultas, creación de tablas temporales, modificaciones de datos, etc) se van acumulando en la RAM (tenemos 43 GB) llega un momento
que tanto el SWAP como la memoria disponible se registra al 100% y no nos queda otra que reiniciar el servicio. 
Existe alguna manera de hacer que la memoria se libere de manera automática después de correr algún proceso???
postgres hace eso de forma normal... puedes mostrar la configuración que
tienen actualmente?
Adjunto una pantalla con el comando "top" corrido en nuestro servidor.
no llego... aunque ademas me gustaria ver que dice pg_stat_activity sobre
lo que esta pasando en la base
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL
Soporte 24x7, desarrollo, capacitación y servicios
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda-RDL/***@public.gmane.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
Jaime Casanova
2011-06-30 08:53:06 UTC
Permalink
te adjunto mi archivo postgres.conf (si no pasa tendré que pegarlo)
algunas configuraciones que no me parece que esten bien:

- shared_buffers = 2048MB
supongo que 43Gb de RAM tranquilamente podrias darle al menos 8Gb a
shared buffers

- temp_buffers = 128MB
cual es la razon de poner este valor tan alto?

- work_mem = 64MB
esto es peligroso y quiza sea la causa de lo que estas viendo

tienes max_connections en 512 y c/u de esas conexiones puede
utilizar hasta work_mem memoria para ordenamientos o tablas hash... si
estas procesando algo para lo que requiere una o varias de esas
operaciones tranquilamente te puedes quedar sin memoria...

por ejemplo imagina que en algun momento las 512 conexiones estan
activas y cada una ordenando una gran cantidad de datos... para eso
requeririas (512*64MB=32768MB) 32Gb

bajalo a 32 o 16 Mb o baja max_connections

- max_stack_depth = 7MB
en serio necesitan tener esto en 7MB, en realidad no se si les pueda
causar un problema pero generalmente me parece que subir esto es mas
parte de esconder un problema...

- effective_cache_size = 4096MB
esto lo podrias tener mas alto... 15 o 20 Gb? asi la base sabe que el SO
tiene suficiente memoria para su cache y otras cosas...

que dice el comando free a todo esto? podrias mostrar la salida de free
antes de hacer algun cambio?
aunque ademas me gustaria ver que dice pg_stat_activity sobre
lo que esta pasando en la base
te refieres a que ejecute "select * from pg_stat_activity" y que te envié el resultado ???
exactamente
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL
Soporte 24x7, desarrollo, capacitación y servicios
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda-RDL/***@public.gmane.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
felix gonzales
2011-06-30 13:49:40 UTC
Permalink
Jaime esto muestra el free

total used free shared buffers cached
Mem: 43132744 42929092 203652 0 13204 11795108
-/+ buffers/cache: 31120780 12011964
Swap: 16771852 5305632 11466220

te adjunto lo que muestra el pg_stat_activity
Post by Jaime Casanova
te adjunto mi archivo postgres.conf (si no pasa tendré que pegarlo)
- shared_buffers = 2048MB
supongo que 43Gb de RAM tranquilamente podrias darle al menos 8Gb a
shared buffers
- temp_buffers = 128MB
cual es la razon de poner este valor tan alto?
- work_mem = 64MB
esto es peligroso y quiza sea la causa de lo que estas viendo
tienes max_connections en 512 y c/u de esas conexiones puede
utilizar hasta work_mem memoria para ordenamientos o tablas hash... si
estas procesando algo para lo que requiere una o varias de esas
operaciones tranquilamente te puedes quedar sin memoria...
por ejemplo imagina que en algun momento las 512 conexiones estan
activas y cada una ordenando una gran cantidad de datos... para eso
requeririas (512*64MB=32768MB) 32Gb
bajalo a 32 o 16 Mb o baja max_connections
- max_stack_depth = 7MB
en serio necesitan tener esto en 7MB, en realidad no se si les pueda
causar un problema pero generalmente me parece que subir esto es mas
parte de esconder un problema...
- effective_cache_size = 4096MB
esto lo podrias tener mas alto... 15 o 20 Gb? asi la base sabe que el SO
tiene suficiente memoria para su cache y otras cosas...
que dice el comando free a todo esto? podrias mostrar la salida de free
antes de hacer algun cambio?
aunque ademas me gustaria ver que dice pg_stat_activity sobre
lo que esta pasando en la base
te refieres a que ejecute "select * from pg_stat_activity" y que
te envié el resultado ???
exactamente
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL
Soporte 24x7, desarrollo, capacitación y servicios
--
Ing. Felix Gonzales
(c) 979720762
Marcos Ortiz
2011-06-30 14:46:36 UTC
Permalink
1- Debes revisar tu aplicación si está cerrando correctamente las
transacciones, porque veo
que tienes muchos procesos IDLE y ese problema muchas veces está derivado
de la aplicación.
Específicamente en la base de datos siganew.

2- Haz algo como esto:
SELECT
procpid,
waiting,
current_timestamp - least(query_start,xact_start) AS runtime,
substr(current_query,1,100) AS current_query
FROM
pg_stat_activity
WHERE NOT procpid=pg_backend_pid();

para ver el tiempo de ejecución y estado de los procesos

3- Si pudieras adjuntar un historial aunque sea de 1 min de vmstat y
iostat también podríamos
ayudarte un poco más.
# vmstat -n 1 10

# iostat -k -p 1 2

# ps auxww | grep "postgres: " | sort -k 9

Si el resultado de ps, te da como resultado varios IDLE IN TRANSACTION,
debes mirar
el código de tu aplicación

Saludos
Post by felix gonzales
Jaime esto muestra el free
total used free shared buffers cached
Mem: 43132744 42929092 203652 0 13204 11795108
-/+ buffers/cache: 31120780 12011964
Swap: 16771852 5305632 11466220
te adjunto lo que muestra el pg_stat_activity
te adjunto mi archivo postgres.conf (si no pasa tendré que pegarlo)
- shared_buffers = 2048MB
supongo que 43Gb de RAM tranquilamente podrias darle al menos 8Gb a
shared buffers
- temp_buffers = 128MB
cual es la razon de poner este valor tan alto?
- work_mem = 64MB
esto es peligroso y quiza sea la causa de lo que estas viendo
tienes max_connections en 512 y c/u de esas conexiones puede
utilizar hasta work_mem memoria para ordenamientos o tablas hash... si
estas procesando algo para lo que requiere una o varias de esas
operaciones tranquilamente te puedes quedar sin memoria...
por ejemplo imagina que en algun momento las 512 conexiones estan
activas y cada una ordenando una gran cantidad de datos... para eso
requeririas (512*64MB=32768MB) 32Gb
bajalo a 32 o 16 Mb o baja max_connections
- max_stack_depth = 7MB
en serio necesitan tener esto en 7MB, en realidad no se si les pueda
causar un problema pero generalmente me parece que subir esto es mas
parte de esconder un problema...
- effective_cache_size = 4096MB
esto lo podrias tener mas alto... 15 o 20 Gb? asi la base sabe que el SO
tiene suficiente memoria para su cache y otras cosas...
que dice el comando free a todo esto? podrias mostrar la salida de free
antes de hacer algun cambio?
aunque ademas me gustaria ver que dice pg_stat_activity sobre
lo que esta pasando en la base
te refieres a que ejecute "select * from pg_stat_activity" y que
te envié el resultado ???
exactamente
--
Jaime Casanova www.2ndQuadrant.com <http://www.2ndQuadrant.com>
Professional PostgreSQL
Soporte 24x7, desarrollo, capacitación y servicios
--
Ing. Felix Gonzales
(c) 979720762
-
http://www.postgresql.org/mailpref/pgsql-es-ayuda
--
Marcos Luís Ortíz Valmaseda
Software Engineer (UCI)
http://marcosluis2186.posterous.com
http://twitter.com/marcosluis2186
felix gonzales
2011-06-30 16:14:15 UTC
Permalink
gracias Marco, paso a responderte...
Post by Marcos Ortiz
**
1- Debes revisar tu aplicación si está cerrando correctamente las
transacciones, porque veo
que tienes muchos procesos IDLE y ese problema muchas veces está derivado
de la aplicación.
Específicamente en la base de datos siganew.
SELECT
procpid,
waiting,
current_timestamp - least(query_start,xact_start) AS runtime,
substr(current_query,1,100) AS current_query
FROM
pg_stat_activity
WHERE NOT procpid=pg_backend_pid();
para ver el tiempo de ejecución y estado de los procesos
aquí el resultado de la consulta

procpid waiting runtime current_query
20191 False 00:00:00.480706 SELECT count(depe_id) FROM estadisticas WHERE
esta_identificador='PORTALES' and depe_id=4
20192 False 00:00:00.386197 <IDLE>
20193 False 00:00:00.923059 <IDLE>
20356 False 00:00:00.025542 "SELECT a.*, b.pers_apellpaterno||'
'||b.pers_apellmaterno||' '||b.p"
20195 False 00:00:00.386546 <IDLE>
*20355 False 00:21:16.105578 <IDLE>*
20337 False 00:00:00.016017 <IDLE>
20198 False 00:00:00.938753 <IDLE>
20199 False 00:00:00.372024 <IDLE>
20200 False 00:00:00.25493 <IDLE>
20201 False 00:00:00.737709 <IDLE>
20202 False 00:00:00.25672 <IDLE>
20203 False 00:00:00.073319 <IDLE>
20330 False 00:00:36.45948 <IDLE>
20205 False 00:00:01.528662 <IDLE>
20206 False 00:00:02.344311 <IDLE>
20207 False 00:00:00.494526 <IDLE>
20208 False 00:00:00.605292 <IDLE>
20209 False 00:00:01.271361 <IDLE>
20350 False 00:00:00.664512 <IDLE>
20211 False 00:00:00.089469 <IDLE>
20212 False 00:00:00.415914 <IDLE>
20213 False 00:00:01.415578 <IDLE>
20214 False 00:00:01.415396 <IDLE>
20215 False 00:00:00.089136 <IDLE>
20216 False 00:00:03.255382 <IDLE>
20217 False 00:00:00.414608 <IDLE>
20218 False 00:00:00.712893 <IDLE>
20394 False 00:15:16.820199 <IDLE>
20220 False 00:00:00.012025 <IDLE>
20221 False 00:00:00.566778 <IDLE>
20224 False 00:00:01.488197 <IDLE>
*20248 False 00:15:02.336603 <IDLE>*
*20259 False 00:29:55.395372 <IDLE>*
2*0260 False 00:29:55.322777 <IDLE>*
*20261 False 00:29:49.844099 <IDLE>*
*20263 False 00:29:35.91811 <IDLE>*
*20264 False 00:29:29.938763 <IDLE>*
20265 False 00:15:13.597104 <IDLE>
20266 False 00:29:34.070183 <IDLE>
20267 False 00:14:39.723603 <IDLE>
20269 False 00:15:11.412347 <IDLE>
*20270 False 00:29:32.580263 <IDLE>*
*20277 False 00:29:26.742965 <IDLE>*
20317 False 00:00:06.020122 <IDLE>
*20395 False 00:15:13.600668 <IDLE>*
*20402 False 00:13:33.794011 <IDLE>*
20520 False 00:00:24.907521 <IDLE>
20521 False 00:00:36.55953 <IDLE>
20522 False 00:00:36.157622 <IDLE>
20529 False 00:00:16.409113 <IDLE>
20530 False 00:00:02.556944 <IDLE>

esos procesos que no tienen query y que demandan mucho tiempo (los
resaltados), crees que sea porque en mi aplicación haya conexiones no
cerradas???, te comento que utilizo también pgpool.
3- Si pudieras adjuntar un historial aunque sea de 1 min de vmstat y iostat
Post by Marcos Ortiz
también podríamos
ayudarte un poco más.
# vmstat -n 1 10
te adjunto el resultado
# iostat -k -p 1 2
Post by Marcos Ortiz
# ps auxww | grep "postgres: " | sort -k 9
Si el resultado de ps, te da como resultado varios IDLE IN TRANSACTION,
debes mirar
el código de tu aplicación
he notado que hay varios IDLE (pero no IDLE IN TRANSACTION, es lo mismo???)
te comento que tengo varios usuarios que se conectan simultaneamente.
Post by Marcos Ortiz
Saludos
Jaime esto muestra el free
total used free shared buffers cached
Mem: 43132744 42929092 203652 0 13204 11795108
-/+ buffers/cache: 31120780 12011964
Swap: 16771852 5305632 11466220
te adjunto lo que muestra el pg_stat_activity
Post by Jaime Casanova
te adjunto mi archivo postgres.conf (si no pasa tendré que pegarlo)
- shared_buffers = 2048MB
supongo que 43Gb de RAM tranquilamente podrias darle al menos 8Gb a
shared buffers
- temp_buffers = 128MB
cual es la razon de poner este valor tan alto?
- work_mem = 64MB
esto es peligroso y quiza sea la causa de lo que estas viendo
tienes max_connections en 512 y c/u de esas conexiones puede
utilizar hasta work_mem memoria para ordenamientos o tablas hash... si
estas procesando algo para lo que requiere una o varias de esas
operaciones tranquilamente te puedes quedar sin memoria...
por ejemplo imagina que en algun momento las 512 conexiones estan
activas y cada una ordenando una gran cantidad de datos... para eso
requeririas (512*64MB=32768MB) 32Gb
bajalo a 32 o 16 Mb o baja max_connections
- max_stack_depth = 7MB
en serio necesitan tener esto en 7MB, en realidad no se si les pueda
causar un problema pero generalmente me parece que subir esto es mas
parte de esconder un problema...
- effective_cache_size = 4096MB
esto lo podrias tener mas alto... 15 o 20 Gb? asi la base sabe que el SO
tiene suficiente memoria para su cache y otras cosas...
que dice el comando free a todo esto? podrias mostrar la salida de free
antes de hacer algun cambio?
aunque ademas me gustaria ver que dice pg_stat_activity sobre
lo que esta pasando en la base
te refieres a que ejecute "select * from pg_stat_activity" y que
te envié el resultado ???
exactamente
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL
Soporte 24x7, desarrollo, capacitación y servicios
--
Ing. Felix Gonzales
(c) 979720762
-
Para cambiar tu suscripción:http://www.postgresql.org/mailpref/pgsql-es-ayuda
--
Marcos Luís Ortíz Valmaseda
Software Engineer (UCI)
http://marcosluis2186.posterous.com
http://twitter.com/marcosluis2186
--
Ing. Felix Gonzales
(c) 979720762
Jaime Casanova
2011-06-30 18:30:49 UTC
Permalink
esos procesos que no tienen query y que demandan mucho tiempo (los resaltados), crees que sea porque en mi aplicación haya conexiones no cerradas???, te
comento que utilizo también pgpool.
cuando usas pgpool debes asegurarte de que la aplicacion abra y cierre
las conexiones rapidamente (creo que ustedes si lo hacen asi pero seria
bueno que chequearas). Aun asi vas a ver conexiones IDLE a la base pero
esas provienen del pgpool (imagino que por eso en el pg_activity.ods que
me pasaste el client_addr es 127.0.0.1)
he notado que hay varios IDLE (pero no IDLE IN TRANSACTION, es lo mismo???)
te comento que tengo varios usuarios que se conectan simultaneamente.
no, no son lo mismo. el uno es una conexion esperando por hacer algo. lo
otro es una transaccion abierta esperando por hacer algo (el problema es
que esa transaccion puede tener objetos bloqueados que no se liberaran
hasta que la transaccion termine)
Jaime esto muestra el free
 total       used       free     shared    buffers     cached
Mem:      43132744   42929092     203652          0      13204   11795108
-/+ buffers/cache:   31120780   12011964
Swap:     16771852    5305632   11466220
quiza me equivoco, pero hasta donde entiendo eso dice que tienes 31GB
libres... y en algun momento has usado swap (5Gb, bastante)
te adjunto mi archivo postgres.conf (si no pasa tendré que pegarlo)
cambiaste estos parametros? hubo algun cambio?
recuerda que al menos al cambiar shared_buffers debes reiniciar el
servicio y quiza te salga un mensaje sobre SHMMAX
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL
Soporte 24x7, desarrollo, capacitación y servicios
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda-RDL/***@public.gmane.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
felix gonzales
2011-06-30 19:54:52 UTC
Permalink
Post by felix gonzales
Post by felix gonzales
esos procesos que no tienen query y que demandan mucho tiempo (los
resaltados), crees que sea porque en mi aplicación haya conexiones no
cerradas???, te
Post by felix gonzales
comento que utilizo también pgpool.
cuando usas pgpool debes asegurarte de que la aplicacion abra y cierre
las conexiones rapidamente (creo que ustedes si lo hacen asi pero seria
bueno que chequearas). Aun asi vas a ver conexiones IDLE a la base pero
esas provienen del pgpool (imagino que por eso en el pg_activity.ods que
me pasaste el client_addr es 127.0.0.1)
entonces si son conexiones que pertenecen a pgpoll, esto podría quedar así o
hay forma de cerrarlas automáticamente??
Post by felix gonzales
Post by felix gonzales
he notado que hay varios IDLE (pero no IDLE IN TRANSACTION, es lo
mismo???)
Post by felix gonzales
te comento que tengo varios usuarios que se conectan simultaneamente.
no, no son lo mismo. el uno es una conexion esperando por hacer algo. lo
otro es una transaccion abierta esperando por hacer algo (el problema es
que esa transaccion puede tener objetos bloqueados que no se liberaran
hasta que la transaccion termine)
Post by felix gonzales
Jaime esto muestra el free
total used free shared
buffers cached
Post by felix gonzales
Mem: 43132744 42929092 203652 0 13204
11795108
Post by felix gonzales
-/+ buffers/cache: 31120780 12011964
Swap: 16771852 5305632 11466220
quiza me equivoco, pero hasta donde entiendo eso dice que tienes 31GB
libres... y en algun momento has usado swap (5Gb, bastante)
umm.. segun los datos hay 203 MB libres y no 31 Gb como tu lo dices,
siendo así es razonable que ocupe el SWAP ... justamente esto es algo que
preocupa y es el motivo de mi consulta.


exacto! eso justamente lo comente en mi correo inicial ... llega
Post by felix gonzales
Post by felix gonzales
te adjunto mi archivo postgres.conf (si no pasa tendré que
pegarlo)
cambiaste estos parametros? hubo algun cambio?
recuerda que al menos al cambiar shared_buffers debes reiniciar el
servicio y quiza te salga un mensaje sobre SHMMAX
hemos cambiado lo siguiente:

shared_buffers=2048MB esto no se ha movido debido a que la ultima vez que
movimos nos dimos cuenta que la memoria se llenaba mas rápido.

temp_buffers de 128MB se ha cambiado a 16MB

work_mem de 64 MB se ha cambiado a 32MB

max_stack_depth de 7MB se ha cambiado a 4MB

effective_cache_size = 4096MB esto tampoco se ha cambiado.

y aún así nuestro problema persiste!



--
Post by felix gonzales
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL
Soporte 24x7, desarrollo, capacitación y servicios
--
Felix Gonzales
felix gonzales
2011-07-04 13:53:47 UTC
Permalink
Amigos sigo con el mismo problema... les comento que el viernes fue la
ultima vez que reiniciamos el servicio y a hoy lunes los 43 GB de RAM esta
al 95% y lo curioso es que tenemos procesos con vigencia de un dia + horas,
pensamos que es por pgpool?? alguien ha tenido este problema??
Post by felix gonzales
Post by felix gonzales
Post by felix gonzales
esos procesos que no tienen query y que demandan mucho tiempo (los
resaltados), crees que sea porque en mi aplicación haya conexiones no
cerradas???, te
Post by felix gonzales
comento que utilizo también pgpool.
cuando usas pgpool debes asegurarte de que la aplicacion abra y cierre
las conexiones rapidamente (creo que ustedes si lo hacen asi pero seria
bueno que chequearas). Aun asi vas a ver conexiones IDLE a la base pero
esas provienen del pgpool (imagino que por eso en el pg_activity.ods que
me pasaste el client_addr es 127.0.0.1)
entonces si son conexiones que pertenecen a pgpoll, esto podría quedar así
o hay forma de cerrarlas automáticamente??
Post by felix gonzales
Post by felix gonzales
he notado que hay varios IDLE (pero no IDLE IN TRANSACTION, es lo
mismo???)
Post by felix gonzales
te comento que tengo varios usuarios que se conectan simultaneamente.
no, no son lo mismo. el uno es una conexion esperando por hacer algo. lo
otro es una transaccion abierta esperando por hacer algo (el problema es
que esa transaccion puede tener objetos bloqueados que no se liberaran
hasta que la transaccion termine)
Post by felix gonzales
Jaime esto muestra el free
total used free shared
buffers cached
Post by felix gonzales
Mem: 43132744 42929092 203652 0 13204
11795108
Post by felix gonzales
-/+ buffers/cache: 31120780 12011964
Swap: 16771852 5305632 11466220
quiza me equivoco, pero hasta donde entiendo eso dice que tienes 31GB
libres... y en algun momento has usado swap (5Gb, bastante)
umm.. segun los datos hay 203 MB libres y no 31 Gb como tu lo dices,
siendo así es razonable que ocupe el SWAP ... justamente esto es algo que
preocupa y es el motivo de mi consulta.
exacto! eso justamente lo comente en mi correo inicial ... llega
Post by felix gonzales
Post by felix gonzales
te adjunto mi archivo postgres.conf (si no pasa tendré que
pegarlo)
cambiaste estos parametros? hubo algun cambio?
recuerda que al menos al cambiar shared_buffers debes reiniciar el
servicio y quiza te salga un mensaje sobre SHMMAX
shared_buffers=2048MB esto no se ha movido debido a que la ultima vez que
movimos nos dimos cuenta que la memoria se llenaba mas rápido.
temp_buffers de 128MB se ha cambiado a 16MB
work_mem de 64 MB se ha cambiado a 32MB
max_stack_depth de 7MB se ha cambiado a 4MB
effective_cache_size = 4096MB esto tampoco se ha cambiado.
y aún así nuestro problema persiste!
--
Post by felix gonzales
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL
Soporte 24x7, desarrollo, capacitación y servicios
--
Felix Gonzales
--
Felix Gonzales
Marcos Ortiz
2011-07-04 15:52:19 UTC
Permalink
1- ¿Puedes postear acá tu configuración de PgPool-II?
2- ¿Qué sistema operativo usas? Incluye acá la versión del kernel
si es algún Unix
3- ¿Qué versión específica de PostgreSQL estás usando?
Post by felix gonzales
shared_buffers=2048MB esto no se ha movido debido a que la ultima
vez que movimos nos dimos cuenta que la memoria se llenaba mas rápido.
temp_buffers de 128MB se ha cambiado a 16MB
work_mem de 64 MB se ha cambiado a 32MB
max_stack_depth de 7MB se ha cambiado a 4MB
effective_cache_size = 4096MB esto tampoco se ha cambiado.
y aún así nuestro problema persiste!
¿Puedes postear el log de PostgreSQL a ver que dice?
¿Qué tipo de aplicación tienes?
OLTP, DataWareHouse o Web

Si usas algún Unix, pon acá también el resultado del comando lsof, el
cual se usa para ver la lista de archivos abiertos, lo cual es común
que tengas muchos en servidores de bases de datos, y muchas veces el
límite se agota

Puedes filtrarlo por: lsof | grep postgres

¿Este servidor está dedicado sólo a PostgreSQL? Si no es el caso, te
será muy difícil tracear lo que está pasando en el sistema, porque no
sabrás si es PostgreSQL o si es otro proceso que te está acabando la
memoria.

En el caso muy extremo, esta consulta puede ayudarte a terminar los
backends de PostgreSQL, que tienen abierta una conexión pero no están
haciendo nada por los últimos 10 minutos:
SELECT
pg_terminate_backend(procpid)
FROM pg_stat_activity
WHERE current_query = '<IDLE> in transaction'
AND current_timestamp - query_start > '10 min';

Saludos
--
Marcos Luís Ortíz Valmaseda
Software Engineer (UCI)
Linux User # 418229
http://marcosluis2186.posterous.com
http://twitter.com/marcosluis2186

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda-RDL/qDirzP6MkH2+***@public.gmane.orgg)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
Marcos Ortiz
2011-07-04 20:48:49 UTC
Permalink
Bueno, lo primero con el log de PostgreSQL:
Hay una consulta específica que se ejecuta casi el 80% del tiempo:

SELECT
DISTINCT *
FROM
(
SELECT distinct b.simo_id,
a.smop_id,
b.simo_descripcion as modulo,
a.smop_descripcion,
b.simo_page,
a.smop_page,
c.sist_activo
FROM sistema_modulo_opciones a
LEFT JOIN sistema_modulo b on a.simo_id=b.simo_id
LEFT JOIN sistema c on c.sist_id=b.sist_id
LEFT JOIN usuario_menu d on d.smop_id=a.smop_id
WHERE c.sist_id='0' and a.smop_acceso=1
AND c.sist_activo=1
UNION ALL
SELECT g.simo_id,
c.smop_id,
g.simo_descripcion as modulo,
f.smop_descripcion,
g.simo_page,
f.smop_page,
e.sist_activo
FROM usuario_perfil a
LEFT JOIN perfilu x ON a.perf_id=x.perf_id
LEFT JOIN perfilu_modulo b ON a.perf_id=b.perf_id
LEFT JOIN perfilu_modulo_menu c ON b.pemo_id=c.pemo_id
LEFT JOIN sistema e ON b.sist_id=e.sist_id
LEFT JOIN sistema_modulo_opciones f ON c.smop_id=f.smop_id
LEFT JOIN sistema_modulo g ON f.simo_id=g.simo_id
WHERE a.usua_id= << FALTA EL 2DO VALOR DE LA COMPARACION
AND f.smop_acceso != 9 << ME IMAGINO QUE QUIERES DECIR <>
AND e.sist_id='0' ORDER BY 1,2) AS a ORDER BY 1,2

1- Deberias considerar optimizar esta consulta ¿Realmente necesitas
todos los campos (lo digo por el *)?



Esta otra consulta tiene otro error de sintaxis:

SELECT a.sist_id AS id,
SUBSTR(a.sist_descripcion,1,30) AS descrip
FROM (
SELECT DISTINCT *
FROM (
SELECT DISTINCT
c.sist_id,c.sist_descripcion,c.sist_breve,c.sist_activo
FROM sistema_modulo_opciones a
LEFT JOIN sistema_modulo b on a.simo_id=b.simo_id
LEFT JOIN sistema c on c.sist_id=b.sist_id
LEFT JOIN usuario_menu d on d.smop_id=a.smop_id
LEFT JOIN usuario_modulo e on b.sist_id=e.sist_id
and e.usua_id= << AQUI HAY UN ERROR
WHERE c.sist_activo=1 AND a.smop_acceso=1 UNION ALL
SELECT b.sist_id,
e.sist_descripcion,
e.sist_breve,
e.sist_activo
FROM usuario_perfil a
LEFT JOIN perfilu x ON a.perf_id=x.perf_id
LEFT JOIN perfilu_modulo b ON a.perf_id=b.perf_id
LEFT JOIN sistema e ON b.sist_id=e.sist_id
WHERE a.usua_id=) AS a ORDER BY 1,2) << AQUI
ESTA EL OTRO ERROR

2- Lo otro fue que trataste de actualizar la tabla dependencia, y
espeficamente los campos depe_presentacion y depe_vision, lo cual dice
en el log que son un varchar(500), considera cambiar este campo a TEXT,
que se usa para estos casos

3- para escapar las comillas usa lo que te propone PostgreSQL E'\\

4- El otro error que veo es
2011-07-04 07:08:48.905
PET,"postgres","siganew",29204,"127.0.0.1:33219",4e11ab71.7214,2,"idle",2011-07-04
07:00:49 PET,5/0,0,LOG,08P01,"unexpected EOF on client
connection",,,,,,,,,""

Esto pasa cuando los backends comienzan a saturar la memoria del
servidor, y el S.O comienza a terminar los procesos debido al Linux
OM Killer

Realmente tu aplicacion no creo que esté cerrando las conexiones
correctamente. Hay muchos IDLE en tu log.

Ahora vamos para PgPool-II
==========================
¿Por qué tienes estos valores en /tmp?
socket_dir = '/tmp'
pcp_socket_dir = '/tmp'
backend_socket_dir = '/tmp'
logdir = '/tmp'

El pid_file_name esta en /var/run/pgpool/pgpool.pid lo que es correcto
pero mi consejo es que cambies
socket_dir, pcp_socket y backend_socket_dir a /var/run/pgpool
y el directorio de los logs a /var/log/pgpool:

# mkdir /var/log/pgpool
# chown -R postgres /var/log/pgpool

Usa pgfouine para ver cuales son las consultas que mas son ejecutadas en
tu sistema, arreglalas, y trata de optimizarlas.

Según dice acá
http://postgresql.1045698.n5.nabble.com/unexpected-EOF-on-client-connection-vs-9-0-3-td3412941.html

Francisco Figueiredo Jr. , parece que el error está en pgpool-II que no
está cerrando correctamente las conexiones.

En este caso, trata lo que te dijo Oswaldo y deshabilita pgpool-II a ver
si el problema persiste. En caso que vayas a usar sólo el modo
de connection pooling, trata con PgBouncer a ver que tal.

O sino lee detenidamente la documentación de PgPool-II para estos
parámetros:

num_init_children = 32
max_pool = 16

# If idle for this many seconds, child exits. 0 means no timeout.
child_life_time = 300 # Veo que aca no tienes ningun timeout para
que el proceso se termine en caso de este IDLE. Trata de bajar este
parámetro a 120 (2 minutos) y prueba

# If idle for this many seconds, connection to PostgreSQL closes.
# 0 means no timeout.
connection_life_time = 0 # pon acá 300 y prueba

# If child_max_connections connections were received, child exits.
# 0 means no exit.
child_max_connections = 0

# If client_idle_limit is n (n > 0), the client is forced to be
# disconnected whenever after n seconds idle (even inside an explicit
# transactions!)
# 0 means no disconnect.
client_idle_limit = 0

Espero que resuelvas.
Cualquier duda, vuelve a preguntar.

Saludos
hola Marco... paso a respondert
1- ¿Puedes postear acá tu configuración de PgPool-II?
adjunto la configuración de pgpool
2- ¿Qué sistema operativo usas? Incluye acá la versión del kernel
si es algún Unix
Suse 11 kernel 2. 6
3- ¿Qué versión específica de PostgreSQL estás usando?
9.0.4
shared_buffers=2048MB esto no se ha movido debido a que la ultima
vez que movimos nos dimos cuenta que la memoria se llenaba mas rápido.
temp_buffers de 128MB se ha cambiado a 16MB
work_mem de 64 MB se ha cambiado a 32MB
max_stack_depth de 7MB se ha cambiado a 4MB
effective_cache_size = 4096MB esto tampoco se ha cambiado.
y aún así nuestro problema persiste!
¿Puedes postear el log de PostgreSQL a ver que dice?
adjunto el ultimo log
¿Qué tipo de aplicación tienes?
OLTP, DataWareHouse o Web
Web
Si usas algún Unix, pon acá también el resultado del comando lsof,
el cual se usa para ver la lista de archivos abiertos, lo cual es común
que tengas muchos en servidores de bases de datos, y muchas veces el
límite se agota
Puedes filtrarlo por: lsof | grep postgres
¿Este servidor está dedicado sólo a PostgreSQL? Si no es el caso, te
será muy difícil tracear lo que está pasando en el sistema, porque no
sabrás si es PostgreSQL o si es otro proceso que te está acabando la
memoria.
nuestro servidor es solo para postgres
En el caso muy extremo, esta consulta puede ayudarte a terminar los
backends de PostgreSQL, que tienen abierta una conexión pero no están
SELECT
pg_terminate_backend(procpid)
FROM pg_stat_activity
WHERE current_query = '<IDLE> in transaction'
AND current_timestamp - query_start > '10 min';
no muestra ningún proceso
Saludos
--
Marcos Luís Ortíz Valmaseda
Software Engineer (UCI)
Linux User # 418229
http://marcosluis2186.__posterous.com
<http://marcosluis2186.posterous.com>
http://twitter.com/__marcosluis2186 <http://twitter.com/marcosluis2186>
toda ayuda será bienvenida. gracias.
--
Felix Gonzales
--
Marcos Luís Ortíz Valmaseda
Software Engineer (UCI)
Linux User # 418229
http://marcosluis2186.posterous.com
http://twitter.com/marcosluis2186

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda-RDL/qDirzP6MkH2+***@public.gmane.orgg)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
Jaime Casanova
2011-07-04 20:32:11 UTC
Permalink
Post by Marcos Ortiz
Realmente tu aplicacion no creo que esté cerrando las conexiones
correctamente. Hay muchos IDLE en tu log.
hay mychos IDLE pero esos no son conexiones de la aplicación sino de
pgpool, el cual al iniciar abre un monton de conexiones para tenerlas
listas para cuando la aplicación pida conexiones...

es normal que al
usar un pool de conexiones veas conexiones en IDLE porque el pool mismo
mantienen conexiones persistentes a la base...
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL
Soporte 24x7, desarrollo, capacitación y servicios
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda-RDL/***@public.gmane.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
felix gonzales
2011-07-06 13:21:40 UTC
Permalink
Jaime, quieres decir que estas conexiones pueden estar abiertas mas de
un día (es lo que vemos en el pg_activity) ?????

por otro lado, en nuestras aplicaciones tenemos muchas consultas que se
lanzan con errores de sintaxis, debido a que el usuario genera estas
consultas obviando algunos criterios en el where, (el where siempre esta
presente en toda consulta ) pensamos que esto no debe afectar mucho el
rendimiento de nuestro servicios, considerando que los errores de sintaxis,
postgres lo identifica sin mucho esfuerzo... ustedes que piensan??
Post by Jaime Casanova
Post by Marcos Ortiz
Realmente tu aplicacion no creo que esté cerrando las conexiones
correctamente. Hay muchos IDLE en tu log.
hay mychos IDLE pero esos no son conexiones de la aplicación sino de
pgpool, el cual al iniciar abre un monton de conexiones para tenerlas
listas para cuando la aplicación pida conexiones...
es normal que al
usar un pool de conexiones veas conexiones en IDLE porque el pool mismo
mantienen conexiones persistentes a la base...
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL
Soporte 24x7, desarrollo, capacitación y servicios
--
Felix Gonzales
Álvaro Hernández Tortosa
2011-07-06 14:35:23 UTC
Permalink
Post by felix gonzales
Jaime, quieres decir que estas conexiones pueden estar abiertas mas de
un día (es lo que vemos en el pg_activity) ?????
por otro lado, en nuestras aplicaciones tenemos muchas consultas que se
lanzan con errores de sintaxis, debido a que el usuario genera estas
consultas obviando algunos criterios en el where, (el where siempre esta
presente en toda consulta ) pensamos que esto no debe afectar mucho el
rendimiento de nuestro servicios, considerando que los errores de sintaxis,
postgres lo identifica sin mucho esfuerzo... ustedes que piensan??
Yo no pienso en el rendimiento... sino en la seguridad. Eso de
que los clientes escriban SQL directamente... "apesta" a SQL Injection.
¡¡¡Míralo bien!!!

Saludos,

Álvaro
--
Álvaro Hernández Tortosa


-----------
NOSYS
Networked Open SYStems
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda-RDL/qDirzP6MkH2+***@public.gmane.orgg)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
felix gonzales
2011-07-06 14:48:24 UTC
Permalink
gracias Alvaro.. desde nuestra aplicación solo pueden aplicar el "SELECT
...... WHERE ....." mas no otras instrucciones.
Post by felix gonzales
Post by felix gonzales
Jaime, quieres decir que estas conexiones pueden estar abiertas mas de
un día (es lo que vemos en el pg_activity) ?????
por otro lado, en nuestras aplicaciones tenemos muchas consultas que se
lanzan con errores de sintaxis, debido a que el usuario genera estas
consultas obviando algunos criterios en el where, (el where siempre esta
presente en toda consulta ) pensamos que esto no debe afectar mucho el
rendimiento de nuestro servicios, considerando que los errores de
sintaxis,
Post by felix gonzales
postgres lo identifica sin mucho esfuerzo... ustedes que piensan??
Yo no pienso en el rendimiento... sino en la seguridad. Eso de
que los clientes escriban SQL directamente... "apesta" a SQL Injection.
ĄĄĄMíralo bien!!!
Saludos,
Álvaro
--
Álvaro Hernández Tortosa
-----------
NOSYS
Networked Open SYStems
--
Felix Gonzales
Álvaro Hernández Tortosa
2011-07-06 14:53:29 UTC
Permalink
gracias Alvaro.. desde nuestra aplicación solo pueden aplicar el "SELECT
...... WHERE ....." mas no otras instrucciones.
Lo cual es lo mismo que decir que pueden ejecutar absolutamente
todo... salvo que tengas filtros que eliminen SQL de lo que introducen,
y eso no es nada fácil...

¿Si en el ______ de la derecha del WHERE se escribe algo similar
a:

1=1; DROP TABLE zzzz;

¿qué sucede? (y variaciones sobre lo anterior, claro... como incluir
subselects que borren/actualicen... es sencillo -lo cual funcionaría aun
permitiendo la ejecución de una única sentencia)


Mucho cuidado...

Saludos,

Álvaro
--
Álvaro Hernández Tortosa


-----------
NOSYS
Networked Open SYStems
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda-RDL/qDirzP6MkH2+***@public.gmane.orgg)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
felix gonzales
2011-07-06 15:09:54 UTC
Permalink
la aplicación cierra el WHERE con un "AND depe_id=xxxx" , es probable que
se inserte otro código, pero hasta la fecha no hemos tenido problemas de ese
tipo, (claro que tenemos que afinar ello) pero por ahora necesitamos saber
si postgres requiere de mucho esfuerzo para detectar "errores de sintaxis".
Post by Álvaro Hernández Tortosa
gracias Alvaro.. desde nuestra aplicación solo pueden aplicar el "SELECT
...... WHERE ....." mas no otras instrucciones.
Lo cual es lo mismo que decir que pueden ejecutar absolutamente
todo... salvo que tengas filtros que eliminen SQL de lo que introducen,
y eso no es nada fácil...
¿Si en el ______ de la derecha del WHERE se escribe algo similar
1=1; DROP TABLE zzzz;
¿qué sucede? (y variaciones sobre lo anterior, claro... como incluir
subselects que borren/actualicen... es sencillo -lo cual funcionaría aun
permitiendo la ejecución de una única sentencia)
Mucho cuidado...
Saludos,
Álvaro
--
Álvaro Hernández Tortosa
-----------
NOSYS
Networked Open SYStems
--
Felix Gonzales
Jaime Casanova
2011-07-06 15:25:03 UTC
Permalink
la aplicación cierra el WHERE con un   "AND depe_id=xxxx" , es probable que se inserte otro código, pero hasta la fecha no hemos tenido problemas de ese
tipo, (claro que tenemos que afinar ello) pero por ahora necesitamos saber si  postgres requiere de mucho esfuerzo para detectar "errores de sintaxis".
la mayoria del tiempo no y bien pudiera ser que ustedes encontraran un
bug en ese lado... pero primero hay que agotar todas las opciones
logicas antes de perseguir las ilogicas...

por ejemplo, es obvio que las consultas que si se ejecutan estan
consumiendo muchos recursos (no solo RAM), las has chequeado? sigo
esperando algun EXPLAIN ANALYZE de las consultas mas pesadas y que mas
se ejecutan.

BTW, yo aca tengo un cliente que diariamente genera logs de entre 10 y
20M donde casi todo lo que se graba son errores de "sintaxis incorrecta"
y no han presentado problemas de memoria asi que tiendo a concluir que
ese no es tu problema
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL
Soporte 24x7, desarrollo, capacitación y servicios
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda-RDL/***@public.gmane.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
Marcos Ortiz
2011-07-06 16:22:12 UTC
Permalink
Post by Jaime Casanova
la aplicación cierra el WHERE con un "AND depe_id=xxxx" , es probable que se inserte otro código, pero hasta la fecha no hemos tenido problemas de ese
tipo, (claro que tenemos que afinar ello) pero por ahora necesitamos saber si postgres requiere de mucho esfuerzo para detectar "errores de sintaxis".
la mayoria del tiempo no y bien pudiera ser que ustedes encontraran un
bug en ese lado... pero primero hay que agotar todas las opciones
logicas antes de perseguir las ilogicas...
por ejemplo, es obvio que las consultas que si se ejecutan estan
consumiendo muchos recursos (no solo RAM), las has chequeado? sigo
esperando algun EXPLAIN ANALYZE de las consultas mas pesadas y que mas
se ejecutan.
Toma el consejo de Jaime, y las consultas que te envié antes que
ejecutas mucho, haz un EXPLAIM ANALYZE de las mismas a ver que está
pasando, y trata de optimizarlas.

Usa pgfouine para ver cuales son las más ejcutadas (recuerda los
requerimientos para usarlo, log_statement = all, log_prefix
y el output a CSV)
Post by Jaime Casanova
BTW, yo aca tengo un cliente que diariamente genera logs de entre 10 y
20M donde casi todo lo que se graba son errores de "sintaxis incorrecta"
y no han presentado problemas de memoria asi que tiendo a concluir que
ese no es tu problema
--
Marcos Luís Ortíz Valmaseda
Software Engineer (UCI)
Linux User # 418229
http://marcosluis2186.posterous.com
http://twitter.com/marcosluis2186

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda-RDL/qDirzP6MkH2+***@public.gmane.orgg)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
felix gonzales
2011-07-07 16:48:55 UTC
Permalink
Marco... hemos instalado fouine y la documentación dice lo siguiente:

Then edit your /etc/syslog.conf to set up a PostgreSQL facility:


local0.* -/var/log/pgsql


este archivo no lo tengo en mi sistema (linux Suse v. 11).


You should also ignore PostgreSQL facility for the default log file
otherwise you will log the queries twice:


*.info;mail.none;authpriv.none;cron.none*;local0.none*
/var/log/messages


estos pasos son necesarios, para que sirve esto??
Post by felix gonzales
la aplicación cierra el WHERE con un "AND depe_id=xxxx" , es probable
que se inserte otro código, pero hasta la fecha no hemos tenido problemas de
ese
tipo, (claro que tenemos que afinar ello) pero por ahora necesitamos
saber si postgres requiere de mucho esfuerzo para detectar "errores de
sintaxis".
la mayoria del tiempo no y bien pudiera ser que ustedes encontraran un
bug en ese lado... pero primero hay que agotar todas las opciones
logicas antes de perseguir las ilogicas...
por ejemplo, es obvio que las consultas que si se ejecutan estan
consumiendo muchos recursos (no solo RAM), las has chequeado? sigo
esperando algun EXPLAIN ANALYZE de las consultas mas pesadas y que mas
se ejecutan.
Toma el consejo de Jaime, y las consultas que te envié antes que ejecutas
mucho, haz un EXPLAIM ANALYZE de las mismas a ver que está pasando, y trata
de optimizarlas.
Usa pgfouine para ver cuales son las más ejcutadas (recuerda los
requerimientos para usarlo, log_statement = all, log_prefix
y el output a CSV)
Post by felix gonzales
BTW, yo aca tengo un cliente que diariamente genera logs de entre 10 y
20M donde casi todo lo que se graba son errores de "sintaxis incorrecta"
y no han presentado problemas de memoria asi que tiendo a concluir que
ese no es tu problema
--
Marcos Luís Ortíz Valmaseda
Software Engineer (UCI)
Linux User # 418229
http://marcosluis2186.**posterous.com<http://marcosluis2186.posterous.com>
http://twitter.com/**marcosluis2186 <http://twitter.com/marcosluis2186>
--
Felix Gonzales
felix gonzales
2011-07-06 19:06:37 UTC
Permalink
gracias Jaime voy a prepara lo que me pides y lo envio
Post by felix gonzales
la aplicación cierra el WHERE con un "AND depe_id=xxxx" , es probable
que se inserte otro código, pero hasta la fecha no hemos tenido problemas de
ese
Post by felix gonzales
tipo, (claro que tenemos que afinar ello) pero por
ahora necesitamos saber si postgres requiere de mucho esfuerzo para
detectar "errores de sintaxis".
la mayoria del tiempo no y bien pudiera ser que ustedes encontraran un
bug en ese lado... pero primero hay que agotar todas las opciones
logicas antes de perseguir las ilogicas...
por ejemplo, es obvio que las consultas que si se ejecutan estan
consumiendo muchos recursos (no solo RAM), las has chequeado? sigo
esperando algun EXPLAIN ANALYZE de las consultas mas pesadas y que mas
se ejecutan.
BTW, yo aca tengo un cliente que diariamente genera logs de entre 10 y
20M donde casi todo lo que se graba son errores de "sintaxis incorrecta"
y no han presentado problemas de memoria asi que tiendo a concluir que
ese no es tu problema
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL
Soporte 24x7, desarrollo, capacitación y servicios
--
Felix Gonzales
Álvaro Hernández Tortosa
2011-07-06 16:32:13 UTC
Permalink
Post by felix gonzales
la aplicación cierra el WHERE con un "AND depe_id=xxxx" , es probable que
se inserte otro código, pero hasta la fecha no hemos tenido problemas de ese
tipo, (claro que tenemos que afinar ello) pero por ahora necesitamos saber
si postgres requiere de mucho esfuerzo para detectar "errores de sintaxis".
Bueno, no quiero ser pesado, pero...


... es relativamente sencillo saltarse eso.

A mí me preocuparía bastante la seguridad... antes que el
rendimiento. En cuanto al rendimiento en sí, ya te han contestado.

¡Suerte!

Álvaro
--
Álvaro Hernández Tortosa


-----------
NOSYS
Networked Open SYStems
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda-RDL/qDirzP6MkH2+***@public.gmane.orgg)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
felix gonzales
2011-07-06 13:09:21 UTC
Permalink
gracias Marcos, voy a probar moviendo los parámetros de pgpool y te comento
luego como va..
Post by Marcos Ortiz
SELECT
DISTINCT *
FROM
(
SELECT distinct b.simo_id,
a.smop_id,
b.simo_descripcion as modulo,
a.smop_descripcion,
b.simo_page,
a.smop_page,
c.sist_activo
FROM sistema_modulo_opciones a
LEFT JOIN sistema_modulo b on a.simo_id=b.simo_id
LEFT JOIN sistema c on c.sist_id=b.sist_id
LEFT JOIN usuario_menu d on d.smop_id=a.smop_id
WHERE c.sist_id='0' and a.smop_acceso=1
AND c.sist_activo=1
UNION ALL
SELECT g.simo_id,
c.smop_id,
g.simo_descripcion as modulo,
f.smop_descripcion,
g.simo_page,
f.smop_page,
e.sist_activo
FROM usuario_perfil a
LEFT JOIN perfilu x ON a.perf_id=x.perf_id
LEFT JOIN perfilu_modulo b ON a.perf_id=b.perf_id
LEFT JOIN perfilu_modulo_menu c ON b.pemo_id=c.pemo_id
LEFT JOIN sistema e ON b.sist_id=e.sist_id
LEFT JOIN sistema_modulo_opciones f ON c.smop_id=f.smop_id
LEFT JOIN sistema_modulo g ON f.simo_id=g.simo_id
WHERE a.usua_id= << FALTA EL 2DO VALOR DE LA COMPARACION
AND f.smop_acceso != 9 << ME IMAGINO QUE QUIERES DECIR <>
AND e.sist_id='0' ORDER BY 1,2) AS a ORDER BY 1,2
1- Deberias considerar optimizar esta consulta ¿Realmente necesitas todos
los campos (lo digo por el *)?
SELECT a.sist_id AS id,
SUBSTR(a.sist_descripcion,1,**30) AS descrip
FROM (
SELECT DISTINCT *
FROM (
SELECT DISTINCT c.sist_id,c.sist_descripcion,**
c.sist_breve,c.sist_activo
FROM sistema_modulo_opciones a
LEFT JOIN sistema_modulo b on a.simo_id=b.simo_id
LEFT JOIN sistema c on c.sist_id=b.sist_id
LEFT JOIN usuario_menu d on d.smop_id=a.smop_id
LEFT JOIN usuario_modulo e on b.sist_id=e.sist_id
and e.usua_id= << AQUI HAY UN ERROR
WHERE c.sist_activo=1 AND a.smop_acceso=1 UNION ALL
SELECT b.sist_id,
e.sist_descripcion,
e.sist_breve,
e.sist_activo
FROM usuario_perfil a
LEFT JOIN perfilu x ON a.perf_id=x.perf_id
LEFT JOIN perfilu_modulo b ON a.perf_id=b.perf_id
LEFT JOIN sistema e ON b.sist_id=e.sist_id
WHERE a.usua_id=) AS a ORDER BY 1,2) << AQUI ESTA EL
OTRO ERROR
2- Lo otro fue que trataste de actualizar la tabla dependencia, y
espeficamente los campos depe_presentacion y depe_vision, lo cual dice en el
log que son un varchar(500), considera cambiar este campo a TEXT, que se usa
para estos casos
3- para escapar las comillas usa lo que te propone PostgreSQL E'\\
4- El otro error que veo es
2011-07-04 07:08:48.905 PET,"postgres","siganew",**29204,"127.0.0.1:33219
",**4e11ab71.7214,2,"idle",2011-**07-04 07:00:49 PET,5/0,0,LOG,08P01,"**unexpected
EOF on client connection",,,,,,,,,""
Esto pasa cuando los backends comienzan a saturar la memoria del servidor,
y el S.O comienza a terminar los procesos debido al Linux
OM Killer
Realmente tu aplicacion no creo que esté cerrando las conexiones
correctamente. Hay muchos IDLE en tu log.
Ahora vamos para PgPool-II
==========================
¿Por qué tienes estos valores en /tmp?
socket_dir = '/tmp'
pcp_socket_dir = '/tmp'
backend_socket_dir = '/tmp'
logdir = '/tmp'
El pid_file_name esta en /var/run/pgpool/pgpool.pid lo que es correcto
pero mi consejo es que cambies
socket_dir, pcp_socket y backend_socket_dir a /var/run/pgpool
# mkdir /var/log/pgpool
# chown -R postgres /var/log/pgpool
Usa pgfouine para ver cuales son las consultas que mas son ejecutadas en tu
sistema, arreglalas, y trata de optimizarlas.
Según dice acá
http://postgresql.1045698.n5.**nabble.com/unexpected-EOF-on-**
client-connection-vs-9-0-3-**td3412941.html<http://postgresql.1045698.n5.nabble.com/unexpected-EOF-on-client-connection-vs-9-0-3-td3412941.html>
Francisco Figueiredo Jr. , parece que el error está en pgpool-II que no
está cerrando correctamente las conexiones.
En este caso, trata lo que te dijo Oswaldo y deshabilita pgpool-II a ver si
el problema persiste. En caso que vayas a usar sólo el modo
de connection pooling, trata con PgBouncer a ver que tal.
O sino lee detenidamente la documentación de PgPool-II para estos
num_init_children = 32
max_pool = 16
# If idle for this many seconds, child exits. 0 means no timeout.
child_life_time = 300 # Veo que aca no tienes ningun timeout para
que el proceso se termine en caso de este IDLE. Trata de bajar este
parámetro a 120 (2 minutos) y prueba
# If idle for this many seconds, connection to PostgreSQL closes.
# 0 means no timeout.
connection_life_time = 0 # pon acá 300 y prueba
# If child_max_connections connections were received, child exits.
# 0 means no exit.
child_max_connections = 0
# If client_idle_limit is n (n > 0), the client is forced to be
# disconnected whenever after n seconds idle (even inside an explicit
# transactions!)
# 0 means no disconnect.
client_idle_limit = 0
Espero que resuelvas.
Cualquier duda, vuelve a preguntar.
Saludos
hola Marco... paso a respondert
Post by Marcos Ortiz
1- ¿Puedes postear acá tu configuración de PgPool-II?
adjunto la configuración de pgpool
2- ¿Qué sistema operativo usas? Incluye acá la versión del kernel
si es algún Unix
Suse 11 kernel 2. 6
3- ¿Qué versión específica de PostgreSQL estás usando?
9.0.4
shared_buffers=2048MB esto no se ha movido debido a que la ultima
vez que movimos nos dimos cuenta que la memoria se llenaba mas rápido.
temp_buffers de 128MB se ha cambiado a 16MB
work_mem de 64 MB se ha cambiado a 32MB
max_stack_depth de 7MB se ha cambiado a 4MB
effective_cache_size = 4096MB esto tampoco se ha cambiado.
y aún así nuestro problema persiste!
¿Puedes postear el log de PostgreSQL a ver que dice?
adjunto el ultimo log
¿Qué tipo de aplicación tienes?
OLTP, DataWareHouse o Web
Web
Si usas algún Unix, pon acá también el resultado del comando lsof,
el cual se usa para ver la lista de archivos abiertos, lo cual es común
que tengas muchos en servidores de bases de datos, y muchas veces el
límite se agota
Puedes filtrarlo por: lsof | grep postgres
¿Este servidor está dedicado sólo a PostgreSQL? Si no es el caso, te
será muy difícil tracear lo que está pasando en el sistema, porque no
sabrás si es PostgreSQL o si es otro proceso que te está acabando la
memoria.
nuestro servidor es solo para postgres
En el caso muy extremo, esta consulta puede ayudarte a terminar los
backends de PostgreSQL, que tienen abierta una conexión pero no están
SELECT
pg_terminate_backend(procpid)
FROM pg_stat_activity
WHERE current_query = '<IDLE> in transaction'
AND current_timestamp - query_start > '10 min';
no muestra ningún proceso
Saludos
--
Marcos Luís Ortíz Valmaseda
Software Engineer (UCI)
Linux User # 418229
http://marcosluis2186.__poster**ous.com <http://posterous.com>
<http://marcosluis2186.**posterous.com<http://marcosluis2186.posterous.com>
http://twitter.com/__**marcosluis2186<http://twitter.com/__marcosluis2186><
http://twitter.com/**marcosluis2186 <http://twitter.com/marcosluis2186>>
toda ayuda será bienvenida. gracias.
--
Felix Gonzales
--
Marcos Luís Ortíz Valmaseda
Software Engineer (UCI)
Linux User # 418229
http://marcosluis2186.**posterous.com<http://marcosluis2186.posterous.com>
http://twitter.com/**marcosluis2186 <http://twitter.com/marcosluis2186>
--
Felix Gonzales
Oswaldo
2011-07-04 16:18:55 UTC
Permalink
Post by felix gonzales
Amigos sigo con el mismo problema... les comento que el viernes fue la
ultima vez que reiniciamos el servicio y a hoy lunes los 43 GB de RAM
esta al 95% y lo curioso es que tenemos procesos con vigencia de un dia
+ horas, pensamos que es por pgpool?? alguien ha tenido este problema??
¿Has probado a deshabilitar pgpool y hacer que se conecten directamente
a postgres para verificar si sucede lo mismo?
--
Oswaldo
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda-RDL/qDirzP6MkH2+***@public.gmane.orgg)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
felix gonzales
2011-07-04 17:00:57 UTC
Permalink
gracias Oswaldo, si eso estamos haciendo, luego de reiniciado el servidor
vemos como el uso de la memoria se incrementa lentamente (igual que
siempre), entonces, parece que pgpool no es el problema.
Post by felix gonzales
Amigos sigo con el mismo problema... les comento que el viernes fue la
Post by felix gonzales
ultima vez que reiniciamos el servicio y a hoy lunes los 43 GB de RAM
esta al 95% y lo curioso es que tenemos procesos con vigencia de un dia
+ horas, pensamos que es por pgpool?? alguien ha tenido este problema??
¿Has probado a deshabilitar pgpool y hacer que se conecten directamente a
postgres para verificar si sucede lo mismo?
--
Oswaldo
-
**)
http://www.postgresql.org/**mailpref/pgsql-es-ayuda<http://www.postgresql.org/mailpref/pgsql-es-ayuda>
--
Felix Gonzales
Oswaldo
2011-07-04 17:36:21 UTC
Permalink
Post by felix gonzales
gracias Oswaldo, si eso estamos haciendo, luego de reiniciado el
servidor vemos como el uso de la memoria se incrementa lentamente (igual
que siempre), entonces, parece que pgpool no es el problema.
Observa si ahora se producen conexiones inactivas y estas van aumentando.

Si es asi el problema creo que esta bastante claro, la aplicación esta
dejando conexiones sin cerrar.
--
Oswaldo
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda-RDL/qDirzP6MkH2+***@public.gmane.orgg)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
felix gonzales
2011-07-04 19:37:10 UTC
Permalink
Post by felix gonzales
gracias Oswaldo, si eso estamos haciendo, luego de reiniciado el
Post by felix gonzales
servidor vemos como el uso de la memoria se incrementa lentamente (igual
que siempre), entonces, parece que pgpool no es el problema.
Observa si ahora se producen conexiones inactivas y estas van aumentando.
Si es asi el problema creo que esta bastante claro, la aplicación esta
dejando conexiones sin cerrar.
ummm si ejecuto pg_activity no me muestra actividad... entonces las
conexiones si se están cerrando.
Post by felix gonzales
--
Oswaldo
-
**)
http://www.postgresql.org/**mailpref/pgsql-es-ayuda<http://www.postgresql.org/mailpref/pgsql-es-ayuda>
--
Felix Gonzales
Jaime Casanova
2011-07-04 17:19:34 UTC
Permalink
Post by Jaime Casanova
                         total       used       free     shared    buffers     cached
        Mem:      43132744   42929092     203652          0      13204   11795108
        -/+ buffers/cache:   31120780   12011964
        Swap:     16771852    5305632   11466220
quiza me equivoco, pero hasta donde entiendo eso dice que tienes 31GB
libres... y en algun momento has usado swap (5Gb, bastante)
umm.. segun los datos hay 203 MB  libres y no 31 Gb como tu lo dices, siendo así es razonable que ocupe el SWAP ... justamente esto es algo que preocupa y
es el motivo de mi consulta.
mmm... haber, yo si estoy equivocado pero igual la memoria libre en tu
sistema es de 12Gb... porque 12Gb porque si ves la columna free en la
segunda linea (la que indica -/+ buffers/cache) esa es la memoria que
puedes llegar a usar el asunto es que es memoria que esta siendo usada
como cache y si la llegas a usar primero debes "limpiarla" pero eso
ocurre automaticamente...

de donde sacas que solo tienes 203Mb libres? si es la primera fila
columna free, ese no es el que deberias estar viendo...

si me molesta ver tanto swap usado

ahora, acabo de subir a una tabla el log que pasaste y ejecute esta
consulta:
"""
select * from postgres_log where message like '%temp%' order by 1
"""

y muestra varios REINDEX y 3 selects que requirieron usar archivos
temporales (y segun tu configuracion solo aparecen cuando usan mas de
40Mb), yo empezaria chequeando esos SELECTs
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL
Soporte 24x7, desarrollo, capacitación y servicios
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda-RDL/***@public.gmane.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
felix gonzales
2011-07-04 19:32:34 UTC
Permalink
Post by felix gonzales
Post by Jaime Casanova
Post by felix gonzales
total used free shared
buffers cached
Post by Jaime Casanova
Post by felix gonzales
Mem: 43132744 42929092 203652 0
13204 11795108
Post by Jaime Casanova
Post by felix gonzales
-/+ buffers/cache: 31120780 12011964
Swap: 16771852 5305632 11466220
quiza me equivoco, pero hasta donde entiendo eso dice que tienes 31GB
libres... y en algun momento has usado swap (5Gb, bastante)
umm.. segun los datos hay 203 MB libres y no 31 Gb como tu lo dices,
siendo así es razonable que ocupe el SWAP ... justamente esto es algo que
preocupa y
Post by Jaime Casanova
es el motivo de mi consulta.
mmm... haber, yo si estoy equivocado pero igual la memoria libre en tu
sistema es de 12Gb... porque 12Gb porque si ves la columna free en la
segunda linea (la que indica -/+ buffers/cache) esa es la memoria que
puedes llegar a usar el asunto es que es memoria que esta siendo usada
como cache y si la llegas a usar primero debes "limpiarla" pero eso
ocurre automaticamente...
nosotros siempre nos hemos guiado por la primera linea ya que el "top"
muestra lo mismo, la segunda fila hace referencia a "buffers/cache" como se
entiende esto??
Post by felix gonzales
de donde sacas que solo tienes 203Mb libres? si es la primera fila
columna free, ese no es el que deberias estar viendo...
si me molesta ver tanto swap usado
ahora, acabo de subir a una tabla el log que pasaste y ejecute esta
"""
select * from postgres_log where message like '%temp%' order by 1
"""
y muestra varios REINDEX y 3 selects que requirieron usar archivos
temporales (y segun tu configuracion solo aparecen cuando usan mas de
40Mb), yo empezaria chequeando esos SELECTs
revisaré esto que nos comentas.
--
Post by felix gonzales
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL
Soporte 24x7, desarrollo, capacitación y servicios
--
Felix Gonzales
Loading...