Enviado desde mi iPhone
Inicio del mensaje reenviado: > De: Anthony Sotolongo León <asotolo...@gmail.com> > Fecha: 13 de agosto de 2015, 16:46:20 GMT-3 > Para: "Ivan Perales M." <ivan.pera...@gmail.com> > Cc: Ayuda Esp PostgreSQL <pgsql-es-ayuda@postgresql.org> > Asunto: Re: [pgsql-es-ayuda] 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 <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. >
