On 15/01/2019 5:55 AM, Carlos T. Groero Carmona 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?
Tienes New Relic, usa New Relic para monitorear el 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.
>
> Saludos,
> Carlos
>
> On Sat, Jan 12, 2019 at 4:44 PM Eduardo Morras <emorrasg(at)yahoo(dot)es
> <mailto:emorrasg(at)yahoo(dot)es>> wrote:
>
> On Thu, 10 Jan 2019 22:08:59 -0600
> "Carlos T. Groero Carmona" <ctonetg(at)gmail(dot)com
> <mailto:ctonetg(at)gmail(dot)com>> wrote:
>
> > >
> > > Hola amigos,
> > >>
> > >
> > Hoy volvio a suceder la situacion con los locks, la situacion fue la
> > misma y en la misma tabla, la query es casi la misma, recivimos una
> > alerta de New Relic, el uso del CPU subio ~100%. Revisamos la tabla
> > pg__stat_activity, existian ~ 375 procesos en espera de escribir en
> > la tabla donde estaba el lock, encontramos el lock, lo eliminamos y
> > el resto de los procesos desaparecieron.
> >
> > revisando los logs encontre:
> > LOG: process 1234 still waiting for ShareLock on transaction
> zzzzzzzz
> > after 5000.237 ms
> > 1234 ERROR: canceling statement due to lock timeout ...el
> mismo PID
> > nota: lock_timeout = 10s
> >
> > y por cada update que estaba esperando encontre un sharedlock,
> pero no
> > habia nada en los logs acerca de los insert que encontre en
> > pg_stat_activity que ivan a ejecutarse en la misma tabla donde
> > estaban los locks.
> >
> > Calcule el thresold de la tabla y es solo un 24%.
> >
> > Pos lo que les quiero preguntar:
> > 1. hay alguna manera de prevenir que esto suceda?
> > 2. Existe alguna herramienta para monitorear los locks de mi base de
> > datos?
> >
>
> Nuevamente, la mejor medida que se puede tomar es disminuir el
> número de conexiones. En el primer correo decías que tenías 600,
> es una exageración, incluso para un servidor con 128 núcleos. En
> este caso, al llegar a 377 transacciones el sistema quedo en
> deadlock. Disminuye el número de conexiones a 32 o 40 y usa
> pgbouncer por delante para soportar el volumen de conexiones. Te
> aseguro que usarás casi todos los núcleos si usas PG10+.
>
> Puede que tengas procesadores de sobra y memoria de sobra, pero el
> sistema operativo también impone límites, así como los discos
> duros y resto del hardware. Tantas transaciones se "pegan" por
> adquirir acceso a los recursos más debiles, provocando que la
> mayor parte del tiempo de proceso se pierda en gestionar los
> accesos a dichos recursos, por ejemplo el tiempo de lectura y
> escritura a los discos es finito o el número de descriptores de
> archivo que permite el sistema ser bajo para tu configuración de
> postgres.
>
> El valor de work_mem que sugerí, era un aumento sobre el valor por
> defecto de postgres para poder procesar transacciones más
> complejas usando solo memoria, sin archivos temporales más lentos.
> Si ya lo tenias en 128MB, no hace falta disminuirla. No obstante,
> esos 128MB se multiplican por cada conexión abierta y dado que hay
> 600 son muchos recursos de memoria desperdiciados.
>
> Insisto, la solución creo que va más por problema de arquitectura
> que de configuración, usa pgbouncer, lo puedes instalar incluso en
> el mismo servidor y disminuye el número de conexiones en postgres
> a 20-40, pgbouncer se encargará de gestionar todas las conexiones,
> 300 o 600 o 1000, de manera transparente para Postgresql. Además
> podrás aumentar también el work_mem todavía más
>
> > En fin, cualquier ayuda o sugerencia sera apreciada.
> >
> > Saludos
>
> Saludos
>
> --- ---
> Eduardo Morras <emorrasg(at)yahoo(dot)es <mailto:emorrasg(at)yahoo(dot)es>>
>