On Sat, 5 Jan 2019 18:40:41 -0600 "Carlos T. Groero Carmona" <cton...@gmail.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 <emorr...@yahoo.es>
