Re: Dificil situacion con Lokcs...

From: Horacio Miranda <hmiranda(at)gmail(dot)com>
To: "Carlos T(dot) Groero Carmona" <ctonetg(at)gmail(dot)com>, Eduardo Morras <emorrasg(at)yahoo(dot)es>
Cc: Lista PostgreSql <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: Dificil situacion con Lokcs...
Date: 2019-01-19 20:32:22
Message-ID: 22838188-7205-55ca-cd7d-1d2a0b64a45c@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda


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
>

In response to

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Horacio Miranda 2019-01-19 20:34:55 Re: Dificil situacion con Lokcs...
Previous Message Horacio Miranda 2019-01-19 20:22:57 Re: Dificil situacion con Lokcs...