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>
