Re: Dificil situacion con Lokcs...

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>