Re: Re: [pgsql-es-ayuda] Recomendación sobre el tiempo idle de las conexiones

From: gleon(dot)cl(at)gmail(dot)com
To: "Ivan Perales M(dot)" <ivan(dot)perales(at)gmail(dot)com>
Cc: Anthony Sotolongo <asotolongo(at)gmail(dot)com>, Ayuda Esp PostgreSQL <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: Re: [pgsql-es-ayuda] Recomendación sobre el tiempo idle de las conexiones
Date: 2015-08-13 22:27:26
Message-ID: C2086544-33DE-46BD-926E-B45D140A2049@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

R

Enviado desde mi iPhone

> El 13-08-2015, a las 16:38, Ivan Perales M. <ivan(dot)perales(at)gmail(dot)com> 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 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>:
>>
>>
>>> 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>:
>>>> 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.

In response to

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message gleon.cl 2015-08-14 00:28:02 Fwd: Recomendación sobre el tiempo idle de las conexioneswe
Previous Message Anthony Sotolongo León 2015-08-13 19:46:20 Re: Recomendación sobre el tiempo idle de las conexiones