Re: procesos ocupan el total de la RAM

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
>
> 2011/7/4 Marcos Ortiz <mlortiz(at)uci(dot)cu <mailto:mlortiz(at)uci(dot)cu>>
>
> 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
>
>
> 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!
>
> ¿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
> 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';
>
>
> 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