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

Hola nuevamente Ivan

El 13-08-2015 a las 16:38, Ivan Perales M. escribió:
> Muchas gracias por sus comentarios.
>
> Con respecto a las bases de datos, si tienen razón en que debí usar
> mejor schemas, pero ya que todo lo hago atravéz de jdbc, se me hizo
> más facil solo resolver una base de datos diferente dependiendo el
> cliente seleccionado, en lugar de estar asignando el schema a los
> queries, desconosco si el driver de postgres se pueda asignar el
> search_path por thread, aunque voy a tener que investigar mas a fondo.
>
> Con respecto al pgbouncer lo voy a revisar tambien, en su momento no
> lo consideré por que el software no es de alta concurrencia y mientras
> menos dependencias externas para mi mejor.
>
si alguna vez has entrado a instagram, has pasado por un pgbouncer :D,
pues tengo entendido que ellos lo utilizan, puede ser una excelente
referencia de alta concurrencia.
http://highscalability.com/blog/2012/4/9/the-instagram-architecture-facebook-bought-for-a-cool-billio.html

saludos

> 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 <asotolongo(at)gmail(dot)com
> <mailto:asotolongo(at)gmail(dot)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
>> <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.
>
>
>
>
> --
> Lindolfo Iván Perales Mancinas
> Solo existen 10 tipos de personas en el mundo, las que saben binario y
> las que no.