Re: Dificil situacion con Lokcs...

On Wed, 16 Jan 2019 23:42:22 -0600
"Carlos T. Groero Carmona" <ctonetg(at)gmail(dot)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(dot)soler(at)gmail(dot)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
> > (<emorrasg(at)yahoo(dot)es>) escribió:
> >
> >> On Mon, 14 Jan 2019 10:55:56 -0600
> >> "Carlos T. Groero Carmona" <ctonetg(at)gmail(dot)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 <emorrasg(at)yahoo(dot)es>
> >>
> >>
> On Jan 16, 2019 3:41 AM, "Jaime Soler" <jaime(dot)soler(at)gmail(dot)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 (<emorrasg(at)yahoo(dot)es>)
> escribió:
>
> > On Mon, 14 Jan 2019 10:55:56 -0600
> > "Carlos T. Groero Carmona" <ctonetg(at)gmail(dot)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 <emorrasg(at)yahoo(dot)es>
> >
> >

--- ---
Eduardo Morras <emorrasg(at)yahoo(dot)es>