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 <[email protected] <mailto:[email protected]>>
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
-
Enviado a la lista de correo pgsql-es-ayuda ([email protected])
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
