Re: Dificil situacion con Lokcs...

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?

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> wrote:

> On Thu, 10 Jan 2019 22:08:59 -0600
> "Carlos T. Groero Carmona" <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>
>