Re: Dificil situacion con Lokcs...

On Sat, 5 Jan 2019 18:40:41 -0600
"Carlos T. Groero Carmona" <ctonetg(at)gmail(dot)com> wrote:

> Daymel, gracias por su comentario.

>
> 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.

Tengo otra propuesta, aunque faltan muchos datos de tu configuración y que tipo de consultas están haciendo las aplicaciones. Estimo que estas haciendo consultas complejas de lectura y gran cantidad de inserts/updates/deletes (UID).

Disminuye el numero maximo de conexiones de 600 a 50 o 20 y usa pg_bouncer o similar.
No aumentes el valor de shared_buffers a 64GB, pasado cierto umbral, no sirve y malgastas memoria.
Aumenta work_mem a 16MB o 32MB.
Si haces gran cantidad de UID, comprueba que autovacuum esta haciendo su trabajo. Si haces un vaccum + reindex a las tablas, no debería tener mucho trabajo. Si ves que tarda mucho, reconfigura tu autovacuum. (Esta es una "medida a ojo", nuevamente, nos hacen falta más datos para poder ayudarte)

Vigila tus indices,
- estás usando todos los que tienes? Si hay alguno que NO usas, quítalo. Esto aumenta carga de trabajo en UID y mantenimiento y no te sirven para nada[1]
- necesitas algún indice? Mira cuantas veces has leido la tabla entera (Full Table Scan). Esto es costoso y puede ralentizar las lecturas mucho [2]

Estas medidas no incrementan el número de locks para que los síntomas de tu problema desaparezcan, si no intentan acomodar Postgres a la carga de trabajo que estimo tienes, ejecutando menos consultas más rápidamente y necesitando por tanto menor cantidad de recursos, incluidos los locks.

[1]
https://wiki.postgresql.org/wiki/Index_Maintenance
[2]
Creo que es SELECT relname, seq_scan FROM pg_stat_user_tables

--- ---
Eduardo Morras <emorrasg(at)yahoo(dot)es>