Re: Dificil situacion con Lokcs...

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