On 11/01/2019 5:08 PM, Carlos T. Groero Carmona wrote:
Hola amigos,
Hola, puedes por favor revisar ese update ( es posible que lo compartas,
con datos ofuscados sirve ), tengo la sospecha que estas haciendo un
update con un datos sacado de un select y puede que estes haciendo un
select for update en una transacción y ese update esta actualizando algo
que o no tiene indice ( como ya fue mensionado ) o una columna tiene un
trigger con alguna logica de negocio.
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.
SÃ usas new relic, conecta Ruby con New Relic, El Linux ( asumo usas
Linux ) y postrgesql con New Relic. ( son agentes ).
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
Revisa otros ERRORES en los logs, puede que la causa verdadera este
escondida.
De casualidad tienes maquinas con 10G, corriendo con Linux 6 o 6 (
redhat o centos) y entre medio hay un firewall con 1G ?
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.
Pegale una leida a esto,
http://www.moioli.net/progetti/postgres-deadlocks-debugging-guidelines/
ojala puedas hacer un debug de la consulta responsable del timeout.
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?
En fin, cualquier ayuda o sugerencia sera apreciada.
Saludos
