Re: Recomendación sobre el tiempo idle de las conexiones

On 13/08/15 15:52, Ivan Perales M. wrote:
> No creo que pgbouncer sea mi opción, presisamente mi problema es que
> las conexiones se cachean llegando así al límite de las 100
> predeterminadas que vienen en postgres.
>
lo has probado?

> Lo que necesito es algo así como un datasource global al que le pueda
> pasar datasources de bases de datos específicas y éste se encargue de
> checar idle times para cerrar conexiones.
>
el pgbouncer hace algo como eso, chequea parámetros de
configuracion(https://pgbouncer.github.io/config.html) como:

server_lifetime

The pooler will try to close server connections that have been connected
longer than this. Setting it to 0 means the connection is to be used
only once, then closed. [seconds]

Default: 3600.0

server_idle_timeout

If a server connection has been idle more than this many seconds it will
be dropped. If 0 then timeout is disabled. [seconds]

Default: 600.0

server_connect_timeout

If connection and login won’t finish in this amount of time, the
connection will be closed. [seconds]

Default: 15.0

query_timeout

Queries running longer than that are canceled. This should be used only
with slightly smaller server-side statement_timeout, to apply only for
network problems. [seconds]

Default: 0.0 (disabled)

query_wait_timeout

Maximum time queries are allowed to spend waiting for execution. If the
query is not assigned to a server during that time, the client is
disconnected. This is used to prevent unresponsive servers from grabbing
up connections. [seconds]

Default: 0.0 (disabled)

client_idle_timeout

Client connections idling longer than this many seconds are closed. This
should be larger than the client-side connection lifetime settings, and
only used for network problems. [seconds]

Default: 0.0 (disabled)

idle_transaction_timeout

If client has been in “idle in transaction” state longer, it will be
disconnected. [seconds]

Default: 0.0 (disabled)

saludos

> Pero no encontré ninguno y tampoco creo que lo haya, ya que no es un
> muy buen diseño manejar cantidad variables de bases de datos, pero
> bueno, es el diseño que mejor cumple nuestro requerimiento. Creo que
> lo que tendré que hacer es asignar un tiempo de vida a las conexiones
> idle para que se vayan cerrando las conexiones mas viejas, y ya que el
> sistema no es de alta concurrencia, a lo mucho 10 usuarios, espero no
> impacte el performance de estar abriendo conexiones cada cierto tiempo.
>
> Saludos
>
> 2015-08-13 13:00 GMT-05:00 Anthony Sotolongo <asotolongo(at)gmail(dot)com
> <mailto:asotolongo(at)gmail(dot)com>>:
>
> Hola Ivan
>
> On 13/08/15 14:38, Ivan Perales M. wrote:
>
> Buenas tardes, pido su opinión ya que no soy muy bueno
> administrando bases de datos.
>
> Tengo un software el cua maneja bases de datos dinámicas, es
> decir, una base de datos fija principal y se crea una base de
> datos por cada cliente que se registra en el programa. El
> software está desarrollado en java y utilizo BasiDataSource de
> apache como pool de conexiones para cada base de datos.
>
> El software es también cliente-servidor, lo que significa que
> un usuario puede estar trabajando con una base de datos y otro
> usuario con otra, lo que significa que se tienen una o más
> conexiones por cada base de datos, mas aparte un usuario puede
> switchear entre clientes con solo seleccionarlo de un listado,
> lo que implica crear conexiones a esa base de datos si nadie
> la estaba usando.
>
> Hace poco noté que un cliente del software registró mas de 100
> clientes en el programa, y pusieron a una muchacha a cargar
> cierta información a cada cliente, por lo que se crearon 1
> conexión por cada base y a eso le sumamos que otros usuarios
> estaban trabajando con algunos clientes, pues algunas bases de
> datos llegaron a tener hasta 5 conexiones. Llego un momento en
> que se superaron las 100 conexiones predeterminadas para
> usuarios regulares que ya no se pudo trabajar en muchos
> clientes. Al checar en pg_stat_activity efectivamente estaban
> 99 conexiones. El ultimo uso de la mayoria de conexiones tenia
> varios minutos, de entre 3 hasta 10, por lo que seguramente
> fueron las primeras bases de datos que se abrieron.
>
> Lo que me gustaria me aconsejaran es a decidir si aumento el
> numero de conexiones para usuarios regulares u optimizo los
> datasource para que cierren la conexión a por decir 2 o 3
> minutos de que no se utilize. No se que tanto le impacte al
> performance que se esten abriendo nuevas conexiones en lugar
> de mantenerlas abiertas, por poner un ejemplo un usuario
> genera un reporte y comienza a analizar la información, puede
> llevar 10 segundos en lo que genera otro reporte para mejorar
> el análisis ó puede llevarse mas de 10 minutos.
>
> No conocemos los recursos que dispones, pero aumentar el num de
> conexiones en PostgreSQL no vas a resolver mucho, no conozzo como
> tu driver utiliza el pool de conexiones, pero sino no estas
> claro, se te aconseja utilizar alguno, el pgbouncer te puede
> ayudar a resolver el tema
>
> Además, van a existir algunos procesos automáticos que agarren
> cada base de datos para generar reportes utilizando el
> datasource, por lo que yo no tengo control sobre cuantas
> conexiones crea cada uno.
>
> Saludos y gracias por su tiempo
>
> --
> Lindolfo Iván Perales Mancinas
> Solo existen 10 tipos de personas en el mundo, las que saben
> binario y las que no.
>
> Saludos
>
>
>
>
> --
> Lindolfo Iván Perales Mancinas
> Solo existen 10 tipos de personas en el mundo, las que saben binario y
> las que no.