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? 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> > >
