On Wed, 16 Jan 2019 23:42:22 -0600 "Carlos T. Groero Carmona" <cton...@gmail.com> wrote:
> Gracias Jaime y Eduardo por sus comentarios y la documentacion > > Me encuentro trabajando en una propuesta para cambiar el # > max_connection e incluir pgBouncer en la arquitectura. > > Solo una pregunta, si existe una metrica para calcular el > max_connection porque no se encuentra esta informacion en el manual > de postgres y viene por defecto 100 en la instalacion? Por que por defecto viene configurado para conexiones de corta duración y poca carga, del tipo OLTP. Esta no es siempre la carga que va a recibir en todos los casos y a veces los desarrolladores abusan de postgresql dejando las conexiones abiertas (idle in transaction) sin hacer nada, requiriendo más de las realmente necesarias. > Saludos, > Carlos. > > > On Wed, Jan 16, 2019, 3:41 AM Jaime Soler <jaime.so...@gmail.com > wrote: > > > La asignación típica de max_connections suele estar en el orden > > de ((core_count * 2) + effective_spindle_count , que en tu caso > > oscilará entre 24 conexiones, como referencia tienes el artículo de > > la wiki: > > https://wiki.postgresql.org/wiki/Number_Of_Database_Connections > > Aunque hay múltiples libros de tunning de postgres que te podrán > > orientar con ellos. Con respecto a las métricas a estudiar para > > apoyar el cambio de arquitectura, creo que te pueden ayudar, el ver > > la relación de tps o iops vs os switch context según el número > > máximo de conexiones aceptadas. > > > > Un saludo > > > > > > El mié., 16 ene. 2019 a las 1:34, Eduardo Morras > > (<emorr...@yahoo.es>) escribió: > > > >> On Mon, 14 Jan 2019 10:55:56 -0600 > >> "Carlos T. Groero Carmona" <cton...@gmail.com> wrote: > >> > >> > Eduardo gracias por su explicacion, voy a enfocar mis esfuerzos > >> > hacia ahi, creo que el uso de pgBouncer ayudara mucho, solo que > >> > debo demostrar que esto es necesario, estaba evitando proponer > >> > un cambio en la arquitectura por ahora, pero estoy de acuerdo > >> > con usted, la configuracion puede necesitar algunas > >> > puntualizaciones pero un cambio en la arquitectura que mejore el > >> > consumo y gestion de las conexiones seria de muchisima ayuda asi > >> > como una revision mas exaustiva en el uso de los indices como > >> > dijo Alvaro al inicio de este chat. > >> > > >> > Hay alguna manera de demostrar/monitoriar que postgres por el > >> > solo no esta manejando de la mejor manera esta situacion y > >> > requiere la ayuda de una herramienta externa como pgBoncer? > >> > >> Aparte del error que da? No lo se. Puede que haciendo un truss o > >> mirando con dtrace puedas ver que gasta mucho tiempo en gestionar > >> los locks. Hace mucho que no buceo en el desarrollo de Postgres. > >> > >> > Por cierto, anteriormente me equivoque al comentar los recursos > >> > fisicos de este servidor, aqui los rectificos: > >> > Memory: 512 GB > >> > Procesadores: 2 procesadores, 6 cores por procesador, lo que da > >> > 12 a 2.5GHz. > >> > HD: son SAS, 15K RPM 6 Gb/s. > >> > >> Esto si es muy importante, dado que tienes 12 cores reales y no > >> 128, si antes con tantos procesadores te lo aconsejaba ahora es > >> obligado, debes reducir el número máximo de conexiones y usar un > >> pool de conexiones externo como pgbouncer. > >> > >> Para tu caso, pon 20 conexiones e instala pgbouncer. > >> > >> > Saludos, > >> > Carlos > >> > >> Saludos > >> > >> --- --- > >> Eduardo Morras <emorr...@yahoo.es> > >> > >> > On Jan 16, 2019 3:41 AM, "Jaime Soler" <jaime.so...@gmail.com> wrote: > > La asignación típica de max_connections suele estar en el orden > de ((core_count * 2) + effective_spindle_count , que en tu caso > oscilará entre 24 conexiones, como referencia tienes el artículo de > la wiki: > https://wiki.postgresql.org/wiki/Number_Of_Database_Connections > Aunque hay múltiples libros de tunning de postgres que te podrán > orientar con ellos. Con respecto a las métricas a estudiar para > apoyar el cambio de arquitectura, creo que te pueden ayudar, el ver > la relación de tps o iops vs os switch context según el número máximo > de conexiones aceptadas. > > Un saludo > > > El mié., 16 ene. 2019 a las 1:34, Eduardo Morras (<emorr...@yahoo.es>) > escribió: > > > On Mon, 14 Jan 2019 10:55:56 -0600 > > "Carlos T. Groero Carmona" <cton...@gmail.com> wrote: > > > > > Eduardo gracias por su explicacion, voy a enfocar mis esfuerzos > > > hacia ahi, creo que el uso de pgBouncer ayudara mucho, solo que > > > debo demostrar que esto es necesario, estaba evitando proponer un > > > cambio en la arquitectura por ahora, pero estoy de acuerdo con > > > usted, la configuracion puede necesitar algunas puntualizaciones > > > pero un cambio en la arquitectura que mejore el consumo y gestion > > > de las conexiones seria de muchisima ayuda asi como una revision > > > mas exaustiva en el uso de los indices como dijo Alvaro al inicio > > > de este chat. > > > > > > Hay alguna manera de demostrar/monitoriar que postgres por el > > > solo no esta manejando de la mejor manera esta situacion y > > > requiere la ayuda de una herramienta externa como pgBoncer? > > > > Aparte del error que da? No lo se. Puede que haciendo un truss o > > mirando con dtrace puedas ver que gasta mucho tiempo en gestionar > > los locks. Hace mucho que no buceo en el desarrollo de Postgres. > > > > > Por cierto, anteriormente me equivoque al comentar los recursos > > > fisicos de este servidor, aqui los rectificos: > > > Memory: 512 GB > > > Procesadores: 2 procesadores, 6 cores por procesador, lo que da > > > 12 a 2.5GHz. > > > HD: son SAS, 15K RPM 6 Gb/s. > > > > Esto si es muy importante, dado que tienes 12 cores reales y no > > 128, si antes con tantos procesadores te lo aconsejaba ahora es > > obligado, debes reducir el número máximo de conexiones y usar un > > pool de conexiones externo como pgbouncer. > > > > Para tu caso, pon 20 conexiones e instala pgbouncer. > > > > > Saludos, > > > Carlos > > > > Saludos > > > > --- --- > > Eduardo Morras <emorr...@yahoo.es> > > > > --- --- Eduardo Morras <emorr...@yahoo.es>
