Si la creación de una nueva conexió tarda algunos milisegundos, por el
volumen de uso tan mínimo creo que no es problema por lo pronto cerrar
conexiones cada que se termine la transacción.
Saludos y de nuevo muchas gracias por su tiempo a Alvaro y Anthony
2015-08-13 14:12 GMT-05:00 Anthony Sotolongo <asotolo...@gmail.com
<mailto:asotolo...@gmail.com>>:
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
<asotolo...@gmail.com <mailto:asotolo...@gmail.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.
--
Lindolfo Iván Perales Mancinas
Solo existen 10 tipos de personas en el mundo, las que saben binario y
las que no.
