Re: duda sobre pgpool

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