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 <asotolo...@gmail.com
<mailto:asotolo...@gmail.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
<asotolo...@gmail.com <mailto:asotolo...@gmail.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@postgresql.org
<mailto:pgsql-es-ayuda@postgresql.org>)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
--
Raul Andres Gutierrez Alejo
--
Raul Andres Gutierrez Alejo
