R Enviado desde mi iPhone
> El 13-08-2015, a las 16:38, Ivan Perales M. <ivan.pera...@gmail.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 <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>: >>>> 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.
