gracias Marcos, voy a probar moviendo los parámetros de pgpool y te comento luego como va..
2011/7/4 Marcos Ortiz <mlor...@uci.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 <mlor...@uci.cu <mailto:mlor...@uci.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
