Skip site navigation (1) Skip section navigation (2)

Re: procesos ocupan el total de la RAM

From: Marcos Ortiz <mlortiz(at)uci(dot)cu>
To: felix gonzales <jfgonzales(at)gmail(dot)com>
Cc: Jaime Casanova <jaime(at)2ndquadrant(dot)com>, pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: procesos ocupan el total de la RAM
Date: 2011-07-04 20:48:49
Message-ID: 4E122731.2060905@uci.cu (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
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


In response to

Responses

pgsql-es-ayuda by date

Next:From: Alvaro HerreraDate: 2011-07-04 21:00:05
Subject: Re: Consulta utilizando Arrays.
Previous:From: Lazaro Rubén García MartinezDate: 2011-07-04 20:45:34
Subject: Consulta utilizando Arrays.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group