Re: duda sobre pgpool

Al parecer el error es similar a este
(http://www.pgpool.net/mantisbt/view.php?id=107) temas de DISCARD ALL
en idle
pero yo estoy utilizando una version superior, pues dice que ya se
solucionó eso, en mi caso utilizo:

-pgpool-II version 3.4.1 (tataraboshi) (http://www.pgpool.net/mediawiki/images/pgpool-II-3.4.1.tar.gz)
-postgresql PostgreSQL 9.3.9

Alguien ha tenido este problema?

saludos

On 13/07/15 13:09, Anthony Sotolongo wrote:
> reponde entre lineas
>
> On 13/07/15 12:44, raul andrez gutierrez alejo wrote:
>> Hola.
>>
>> sobre el correo respondo.
>>
>>
>> El 13 de julio de 2015, 10:26, Anthony Sotolongo
>> <asotolongo(at)gmail(dot)com <mailto:asotolongo(at)gmail(dot)com>> escribió:
>>
>> Hola Raul, gracias por responder, me quieres decir que si las
>> actividades que están haciendo son muy grandes y consumen mucha
>> memoria compartida se demora en la liberación de memoria y puede
>> ser la causa de que aun esten en DISCARD ALL, ABORT en el estado
>> "idle"? es decir esas actividades no deja que pgpool desocupe la
>> conexión del cliente y postgres, te muestro el resultado de show
>> pool_processes;
>>
>>
>> Para ver el consumo de CPU y RAM debe ser en Sistema Operativo, si es
>> linux un " top -C -U usuario_pstgres" permite ver el consumo, debe
>> buscar en el top el PID que retornar el show pool_processes en la
>> columna pool_backendpid.
>>
>>
>>
> resultado de top -U postgres (ahi estan incluidos los procesos
> clasicos, bgwriter, chepointer, etc), esto lo ejecute en el master
>
>
> 4184 postgres 20 0 321m 9252 5672 S 0.0 0.2 0:00.03 postgres
> 4193 postgres 20 0 321m 9724 6328 S 0.0 0.2 0:00.07 postgres
> 4203 postgres 20 0 318m 5508 3360 S 0.0 0.1 0:00.00 postgres
> 4204 postgres 20 0 320m 8280 5588 S 0.0 0.1 0:00.01 postgres
> 4205 postgres 20 0 321m 9268 5672 S 0.0 0.2 0:00.02 postgres
> 4351 postgres 20 0 322m 10m 6972 S 0.0 0.2 0:00.14 postgres
> 4457 postgres 20 0 322m 9580 6464 S 0.0 0.2 0:00.13 postgres
> 4490 postgres 20 0 322m 9552 6448 S 0.0 0.2 0:00.13 postgres
> 4601 postgres 20 0 321m 9576 6248 S 0.0 0.2 0:00.14 postgres
> 4612 postgres 20 0 322m 10m 7212 S 0.0 0.2 0:00.29 postgres
> 4613 postgres 20 0 321m 9436 6128 S 0.0 0.2 0:00.12 postgres
> 4614 postgres 20 0 318m 5472 3324 S 0.0 0.1 0:00.00 postgres
> 4618 postgres 20 0 322m 10m 7056 S 0.0 0.2 0:00.17 postgres
> 4619 postgres 20 0 318m 5472 3324 S 0.0 0.1 0:00.00 postgres
> 4624 postgres 20 0 318m 5472 3324 S 0.0 0.1 0:00.00 postgres
> 7767 postgres 20 0 316m 13m 13m S 0.0 0.2 0:42.71 postgres
> 7768 postgres 20 0 173m 1320 548 S 0.0 0.0 0:00.03 postgres
> 7770 postgres 20 0 317m 47m 46m S 0.0 0.8 0:03.37 postgres
> 7771 postgres 20 0 316m 2372 1536 S 0.0 0.0 0:04.83 postgres
> 7772 postgres 20 0 316m 4880 4040 S 0.0 0.1 0:04.70 postgres
> 7773 postgres 20 0 317m 3000 1496 S 0.0 0.1 0:32.51 postgres
> 7774 postgres 20 0 176m 1908 640 S 0.0 0.0 0:57.09 postgres
> 7775 postgres 20 0 317m 3068 1452 S 0.0 0.1 0:30.36 postgres
>
>
>> pool_pid | start_time | database |
>> username | create_time | pool_counter
>> ----------+---------------------+-----------------------+------------------------+---------------------+--------------
>> 13160 | 2015-07-13 10:42:11 | |
>> | |
>> 2541 | 2015-07-10 17:51:31 | db_documentacion_sdit |
>> usr_documentacion_sdit | 2015-07-13 09:41:41 | 1
>> 12935 | 2015-07-13 09:57:25 | db_documentacion_sdit |
>> usr_documentacion_sdit | 2015-07-13 10:03:41 | 1
>> 1976 | 2015-07-10 16:09:52 | |
>> | |
>> 1977 | 2015-07-10 16:09:52 | |
>> | |
>> 1978 | 2015-07-10 16:09:52 | db_documentacion_sdit |
>> usr_documentacion_sdit | 2015-07-13 10:14:59 | 1
>> 1979 | 2015-07-10 16:09:52 | |
>> | |
>> 13445 | 2015-07-13 12:13:52 | |
>> | |
>> 1981 | 2015-07-10 16:09:52 | db_documentacion_sdit |
>> usr_documentacion_sdit | 2015-07-13 09:42:22 | 2
>> 13159 | 2015-07-13 10:42:11 | |
>> | |
>> 1983 | 2015-07-10 16:09:52 | db_documentacion_sdit |
>> usr_documentacion_sdit | 2015-07-13 10:15:27 | 1
>> 12936 | 2015-07-13 09:57:25 | db_documentacion_sdit |
>> usr_documentacion_sdit | 2015-07-13 10:04:09 | 1
>> 1985 | 2015-07-10 16:09:52 | |
>> | |
>> 13067 | 2015-07-13 10:20:37 | |
>> | |
>> 1987 | 2015-07-10 16:09:52 | |
>> | |
>> 1988 | 2015-07-10 16:09:52 | db_documentacion_sdit |
>> usr_documentacion_sdit | 2015-07-13 10:14:59 | 2
>> 1989 | 2015-07-10 16:09:52 | db_documentacion_sdit |
>> usr_documentacion_sdit | 2015-07-13 10:14:59 | 1
>> 12869 | 2015-07-13 09:43:33 | db_documentacion_sdit |
>> usr_documentacion_sdit | 2015-07-13 10:15:27 | 1
>> 12866 | 2015-07-13 09:43:33 | |
>> | |
>> 12864 | 2015-07-13 09:43:08 | |
>> | |
>> 12870 | 2015-07-13 09:43:33 | |
>> | |
>> 1994 | 2015-07-10 16:09:52 | db_documentacion_sdit |
>> usr_documentacion_sdit | 2015-07-13 09:41:10 | 1
>> 1995 | 2015-07-10 16:09:52 | |
>> | |
>> 12893 | 2015-07-13 09:51:11 | db_documentacion_sdit |
>> usr_documentacion_sdit | 2015-07-13 10:15:37 | 1
>> 12897 | 2015-07-13 09:52:14 | db_documentacion_sdit |
>> usr_documentacion_sdit | 2015-07-13 09:54:42 | 1
>> 13077 | 2015-07-13 10:24:29 | |
>> | |
>> 13310 | 2015-07-13 11:32:49 | |
>> | |
>> 2000 | 2015-07-10 16:09:52 | db_documentacion_sdit |
>> usr_documentacion_sdit | 2015-07-13 09:42:22 | 1
>> 2001 | 2015-07-10 16:09:52 | db_documentacion_sdit |
>> usr_documentacion_sdit | 2015-07-13 09:42:22 | 1
>> 13194 | 2015-07-13 10:53:30 | postgres |
>> postgres | 2015-07-13 12:13:55 | 1
>> 13131 | 2015-07-13 10:35:50 | |
>> | |
>> 12990 | 2015-07-13 10:03:05 | db_documentacion_sdit |
>> usr_documentacion_sdit | 2015-07-13 10:14:27 | 4
>>
>> y el resultado de la consulta:
>> select pid,state,xact_start,query_start,state_change,query from
>> pg_stat_activity;
>>
>>
>> esta consulta es recomendable ejecutar con una conexión directa a
>> cada postgres, porque si se ejecuta pasando por el pgpool se puede
>> balancear y ejecutar en el master o en el esclavo.
> Si claro el resultado de esta consulta lo hago en el master directo,
> entiendo lo del balanceo ;-)
>
>
>>
>> pid | state | xact_start |
>> query_start | state_change
>> | query
>>
>> ------+--------+-------------------------------+-------------------------------+-------------------------------+-------------------------------------------------
>> -----------------------------------
>> 4351 | idle | | 2015-07-13
>> 09:57:11.52977-03 | 2015-07-13 09:57:11.530004-03 | DISCARD ALL
>> 4601 | idle | | 2015-07-13
>> 10:21:36.21236-03 | 2015-07-13 10:21:36.212696-03 | DISCARD ALL
>> 4184 | idle | | 2015-07-13
>> 09:43:12.427339-03 | 2015-07-13 09:43:12.428155-03 | DISCARD ALL
>> 4457 | idle | | 2015-07-13
>> 10:06:24.988995-03 | 2015-07-13 10:06:24.98923-03 | DISCARD ALL
>> 5936 | active | 2015-07-13 12:18:59.426768-03 | 2015-07-13
>> 12:18:59.426768-03 | 2015-07-13 12:18:59.426775-03 | select
>> pid,state,xact_start,query_start,state_ch
>> ange,query from pg_stat_activity;
>> 4193 | idle | | 2015-07-13
>> 09:47:37.27413-03 | 2015-07-13 09:47:37.274514-03 | DISCARD ALL
>> 4490 | idle | | 2015-07-13
>> 10:06:16.192748-03 | 2015-07-13 10:06:16.19298-03 | DISCARD ALL
>> 4203 | idle | | 2015-07-13
>> 09:44:24.666702-03 | 2015-07-13 09:44:24.667234-03 | DISCARD ALL
>> 4204 | idle | | 2015-07-13
>> 09:44:24.714707-03 | 2015-07-13 09:44:24.714869-03 | DISCARD ALL
>> 4205 | idle | | 2015-07-13
>> 09:44:24.704854-03 | 2015-07-13 09:44:24.705512-03 | DISCARD ALL
>> 4612 | idle | | 2015-07-13
>> 10:28:10.681199-03 | 2015-07-13 10:28:10.681419-03 | ABORT
>> 4613 | idle | | 2015-07-13
>> 10:31:20.242776-03 | 2015-07-13 10:31:20.243073-03 | DISCARD ALL
>> 4614 | idle | | 2015-07-13
>> 10:17:02.001256-03 | 2015-07-13 10:17:02.001493-03 | DISCARD ALL
>> 4618 | idle | | 2015-07-13
>> 10:21:36.722948-03 | 2015-07-13 10:21:36.723194-03 | DISCARD ALL
>> 4619 | idle | | 2015-07-13
>> 10:17:29.934837-03 | 2015-07-13 10:17:29.93506-03 | DISCARD ALL
>> 4624 | idle | | 2015-07-13
>> 10:17:39.546724-03 | 2015-07-13 10:17:39.546923-03 | DISCARD ALL
>> (16 filas)
>>
>>
>> No pudiera ser una mala práctica de la app que no esta haciendo
>> las cosas como debería, de algo asi como no cerrar la transaccion
>> o no cerrar la conexion?
>>
>>
>> si es una mala practica que la app no cierre la conexión
>> correctamente, pero se puede dar si la aplicación es de escritorio
>> por una pantalla azul, si es web el servidor de aplicación se
>> reinicia o si es movil se cae la conexión y en ningún caso se
>> desconecta el cliente correctamente , el parametro client_idle_limit
>> es una medida preventida.
>>
> Me huele que las estan dejando abiertas, pero lo que me resulta raro
> es que client_idle_limit no cierra las conex (pgpool-cliente), a eso
> queria llegar que no las está cerrando aun cuando han superado el
> umbral de client_idle_limit(300) y la app este dejando la conex abiertas.
> ¿algo al respecto?
>
>
>
> saludos y gracias
>
>
>>
>> saludos
>>
>>
>>
>> On 13/07/15 11:41, raul andrez gutierrez alejo wrote:
>>> Hola Anthony.
>>>
>>> Pgpool es un pool de conexiones y no es necesario que al llegar
>>> una conexión al pgpool, pgpool tenga que abrir una conexión a
>>> cada postgres y luego cerrarlas, las conexiones en pgpool y el
>>> postgres se mantiene abiertas, el único problema que eh notado
>>> de esto que si se envía un reporte muy pesado, el backend puede
>>> consumir hasta 1GB de memoria compartida y solo liberar esta
>>> memoria hasta que el pgpool cierre la conexión, pero si su
>>> aplicaciones hace consultas pequeñas y muy parecidas, el tener
>>> la información en la memoria compartida puede tener un muy buen
>>> rendimiento en el planificador y el motor.
>>>
>>> El parámetro client_idle_limit es para que pgpool cierre la
>>> conexión si un cliente del pgpool no cerro la conexión
>>> correctamente.
>>>
>>> Para tener el comportamiento esperado de cerrar el conexión
>>> entre postgres y el pgppol se debe configurar en los postgres el
>>> parámetro "tcp_keepalives_idle", yo lo tengo configurado en
>>> 7200(2horas).
>>>
>>> Para tener en cuenta el pg_stat_activity muestra la activadad
>>> del nodo, para ver la actividad en el pgpool seria "show
>>> pool_pools" mas info en
>>> http://www.pgpool.net/docs/latest/pgpool-en.html#show-commands
>>>
>>>
>>>
>>> El 13 de julio de 2015, 9:01, Anthony Sotolongo
>>> <asotolongo(at)gmail(dot)com <mailto:asotolongo(at)gmail(dot)com>> escribió:
>>>
>>> Estimados, tengo un pgpool configurado para acceder a 2
>>> servidores PostgreSQL con streaming replication, y tengo
>>> estos valores en el pgpool.conf
>>>
>>> # - Life time -
>>>
>>> child_life_time = 300 # Pool exits after being
>>> idle for this many seconds
>>> child_max_connections = 0 # Pool exits
>>> after receiving that many connections
>>> # 0 means no exit
>>> connection_life_time = 420 # Connection to backend
>>> closes after being idle for this many seconds
>>> # 0 means no close
>>> client_idle_limit = 300 # Client is
>>> disconnected after being idle for that many seconds
>>> # (even inside an explicit
>>> transactions!)
>>> # 0 means no disconnection
>>>
>>>
>>> Tengo entendido que client_idle_limit desconectará los
>>> clientes idle luego de (300 seg en este caso)
>>> y que connection_life_time me desconectara de los backend de
>>> postgres luego de (420 seg en este caso)
>>> (no quieren decir que sean los mejores valores o los
>>> definitivos, estamos tratando de ajustarlos)
>>> Estamos tratando de ajustar los valores
>>>
>>> El tema está en que haciendo esta consulta a través del pgpool:
>>> select pid,state,xact_start,query_start,state_change,query
>>> from pg_stat_activity
>>>
>>> obtengo:
>>> 4351 | idle | | 2015-07-13 09:57:11.52977-03 |
>>> 2015-07-13 09:57:11.530004-03 <tel:530004-03> | DISCARD ALL
>>> 4601 | idle | | 2015-07-13 10:21:36.21236-03 |
>>> 2015-07-13 10:21:36.212696-03 | DISCARD ALL
>>> 4184 | idle | | 2015-07-13 09:43:12.427339-03
>>> <tel:427339-03> | 2015-07-13 09:43:12.428155-03
>>> <tel:428155-03> | DISCARD ALL
>>> 4457 | idle | | 2015-07-13 10:06:24.988995-03 |
>>> 2015-07-13 10:06:24.98923-03 | DISCARD ALL
>>> 5032 | active | 2015-07-13 10:51:36.675985-03
>>> <tel:675985-03> | 2015-07-13 10:51:36.675985-03
>>> <tel:675985-03> | 2015-07-13 10:51:36.675992-03
>>> <tel:675992-03> | select
>>> pid,state,xact_start,query_start,state_ch
>>> ange,query from pg_stat_activity
>>> : ;
>>> 4193 | idle | | 2015-07-13 09:47:37.27413-03 |
>>> 2015-07-13 09:47:37.274514-03 <tel:274514-03> | DISCARD ALL
>>> 4490 | idle | | 2015-07-13 10:06:16.192748-03
>>> <tel:192748-03> | 2015-07-13 10:06:16.19298-03 | DISCARD ALL
>>> 4203 | idle | | 2015-07-13 09:44:24.666702-03
>>> <tel:666702-03> | 2015-07-13 09:44:24.667234-03
>>> <tel:667234-03> | DISCARD ALL
>>> 4204 | idle | | 2015-07-13 09:44:24.714707-03 |
>>> 2015-07-13 09:44:24.714869-03 | DISCARD ALL
>>> 4205 | idle | | 2015-07-13 09:44:24.704854-03 |
>>> 2015-07-13 09:44:24.705512-03 | DISCARD ALL
>>> 4612 | idle | | 2015-07-13 10:28:10.681199-03
>>> <tel:681199-03> | 2015-07-13 10:28:10.681419-03
>>> <tel:681419-03> | ABORT
>>> 4613 | idle | | 2015-07-13 10:31:20.242776-03
>>> <tel:242776-03> | 2015-07-13 10:31:20.243073-03
>>> <tel:243073-03> | DISCARD ALL
>>> 4614 | idle | | 2015-07-13 10:17:02.001256-03 |
>>> 2015-07-13 10:17:02.001493-03 | DISCARD ALL
>>> 4618 | idle | | 2015-07-13 10:21:36.722948-03
>>> <tel:722948-03> | 2015-07-13 10:21:36.723194-03
>>> <tel:723194-03> | DISCARD ALL
>>> 4619 | idle | | 2015-07-13 10:17:29.934837-03 |
>>> 2015-07-13 10:17:29.93506-03 | DISCARD ALL
>>> 4624 | idle | | 2015-07-13 10:17:39.546724-03
>>> <tel:546724-03> | 2015-07-13 10:17:39.546923-03
>>> <tel:546923-03> | DISCARD ALL
>>>
>>> La mayoria de las actividades ya pasaron los 300 seg e
>>> incluso los 420 seg de los parametros "client_idle_limit" y
>>> "connection_life_time" y están en estado "idle" y aun estan
>>> conectadas, será que no terminan aun sus querys (DISCARD
>>> ALL, ABORT, ect), o hay algo que no comprendo de los
>>> parametros del pgpool, pues ya paso tiempo y aun ocupan las
>>> conexiones
>>>
>>>
>>> La idea que necesitamos es que luego de un intervalo sin
>>> nada que hacer (estado "idle") se desconecte y desocupe la
>>> conex.
>>>
>>>
>>> Saludos y atentos a sus sugerencias.
>>>
>>> Anthony
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -
>>> Enviado a la lista de correo pgsql-es-ayuda
>>> (pgsql-es-ayuda(at)postgresql(dot)org
>>> <mailto:pgsql-es-ayuda(at)postgresql(dot)org>)
>>> Para cambiar tu suscripción:
>>> http://www.postgresql.org/mailpref/pgsql-es-ayuda
>>>
>>>
>>>
>>>
>>> --
>>> Raul Andres Gutierrez Alejo
>>
>>
>>
>>
>> --
>> Raul Andres Gutierrez Alejo
>