Eduardo gracias por su consejo, coincido con usted y es lo que he estado haciendo. Actualmente el work_mem es the 128 MB, yo estoy de acuerdo con usted que debe ser 32 MB, es el valor que habia puesto en mi propuesta de cambios, pero ahora solo quiero enfocarme en optimizar todo lo que se pueda con respecto a indexes y vacuum. Una vez realizemos el upgrade quiero empezar a usar los indices BRIN donde se pueda. Estas en lo correcto manejamos grandes numeros de transacciones por segundo.
Sobre lo que estaba sucediendo con los locks, se encontro el script que estaba ejecutanto recurrentemente updates sobre las misma tupla, y lse ejecutaban las solicitudesde desde diferentes servidores de aplicacion a la vez.estamos hablando de 388 solicitudes de escritura sobre la misma tupla, ademas de las otras transacciones que el normalmente ejecuta. Lo que no entiendo es porque cae, el consumo de hardware se eleva tanto que el servidor se reinicia. Se que todo tiene un limite, pero 388 transaciones no es ni el 1% de las que maneja ese servidor. Cuando el servidor se reinicia se ve este gran numero de updates sobre la misma tabla en pg_stat_activity, estos procesos se han estado ejecutandose por 20 min, cuando la consulta que he visto en los log que mas se ha demorado rondea los 5s. Ejecutamos pg_cancel_backend() sobre los proceos que mas han estado esperando y los otros desaparecen pasado unos segundos. Automaticamente el uso de los recursos de hardware (RAM, CPU, uso del disco duro) vuelven a disminuir a los valores normales que nunca exeden el 25%. Saludos >
