Re: procesos ocupan el total de la RAM

gracias Marcos, voy a probar moviendo los parámetros de pgpool y te comento
luego como va..

2011/7/4 Marcos Ortiz <mlortiz(at)uci(dot)cu>

> 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<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.__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