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
>
