Re: Dificil situacion con Lokcs...

Daymel, gracias por su comentario.

He estado manejando hipotesis donde el update se bloquea porque se queda
esperando una validacion (otro query o trigger), se demora mas de 5
segundos, el lock_timeout le dice a postgres que elimine esa transaction,
la transaction se queda abierta, el script intenta ejecutar nuevos updates
sobre las mismas filas, y como explico Daymel, esos procesos pasan a ser
locks por transaiones y como en mi configuracion tengo solo 128 y la
ultima vez eran 388 procesos lbloqueados, postgres cae por el alto consumo
de recursos de estas y otras operaciones.

Realize una prueba en un servidor local, la prueba que realize fue, desde
un full backup realizado ayer, restaure toda la estructura de la base de
datos en un servidor local, restaure toda la data de la tabla en la cual
estoy teniendo los locks, y ejecute el mismo update en reiteradas
ocaciones, resultado: No tuve problemas.

Recuerden que las otras tablas estan vacias, y que no tengo llaves foraneas
porque Rails (ruby) se encarga the validar esa parte.

Todo parece indicar que el problema esta en el manejo de transaciones,
exepciones o validaciones en la aplicacion.

Mi propuesta desde este punto para evitar que el servidor caiga de nuevo
hasta que se encuentre el script que esta afectando la base de datos es el
siguiente:
1- Aumentar el shared_buffer a 64 GB como teniamos planificado y asi
postgres tiene mas recursos para trabajar
2- Aumentar 10 veces como me recomendo alvaro el numero de locks por
transaciones
3- Desabilitar el lock_timeout.
4- disminuir el tiempo de log_duration o ponerlo en cero hasta que sel
bloqueo suceda nuevamente y me permita tracear todas las transaciones
realizadas en un tiempo sercano al primer lock en la tabla.

Como siempre, cualquier opinion o sugerencia sera agradecida.
Saludos,
Carlos.

On Sat, Jan 5, 2019 at 5:01 PM Daymel Bonne <daymel(dot)bonne(at)2ndquadrant(dot)ec>
wrote:

> Hola:
>
> El sáb., 5 de ene. de 2019 a la(s) 17:43, Carlos T. Groero Carmona (
> ctonetg(at)gmail(dot)com) escribió:
>
>> Alvaro escribio:
>>>
>>
>> Como tienes lock_timeout, tu problema seguramente no fue de locks sino
>>> de lentitud.
>>>
>>
>> Por lo que me surge la duda, todo parece indicar que la transaction se
>> inicia con el update pero por algun problema de lentitud se queda esperando
>> una respuesta, durante ese tiempo la tabla o la tupla esta lock...
>>
>> Mi lock_timeout es de 10 segundos, por lo tanto despues de 10 segundo esa
>> transacion, sera eliminada?
>>
>> Si se elimina entonces no se recibe ni el commit ni el rollback, por lo
>> tanto cualquier otra transaction que se vaya a ejecutar en esa tabla sera
>> detenida esperando que la transaction anterior se complete ya se por un
>> commit o un rollbacks...
>>
>
> No toda transacción sobre la tabla será bloqueada. Sólo las que necesiten
> del registro que se está actualizando. En tu caso, los updates sobre el
> mismo registro serán encolados.
>
> Saludos
>
> --
> Daymel Bonne
> Database Consultant, Training & Services
> 2ndQuadrant - PostgreSQL Solutions for the Enterprise
> https://www.2ndQuadrant.com/ <https://www.2ndquadrant.com/>
>
>