El equipo de Ubicloud comparte su experiencia de 15 años gestionando servicios de PostgreSQL y explica por qué mantiene activado el overcommit estricto de memoria en el núcleo Linux. La práctica evita que el OOM killer (el mecanismo del kernel que termina procesos cuando se agota la memoria) aborte un backend del gestor de bases de datos y provoque corrupción silenciosa en los búferes compartidos, lo que obligaría al postmaster a detener todas las conexiones y ejecutar una costosa recuperación tras caída.
Con el ajuste vm.overcommit_memory=2 y los parámetros overcommit_kbytes u overcommit_ratio, el kernel rechaza las solicitudes de memoria que excedan CommitLimit con el error ENOMEM. PostgreSQL trata ese fallo de forma controlada: cancela la transacción implicada, mantiene el postmaster en pie y deja intactas las demás conexiones. El artículo detalla la fórmula de cálculo del límite, los casos en los que esta política funciona mejor (servidores dedicados a PostgreSQL con procesos auxiliares conocidos) y sus limitaciones en máquinas compartidas con cargas heterogéneas.
El texto narra además un incidente real: tras activar el overcommit estricto aparecieron errores de falta de memoria en máquinas con RAM libre. La causa fue un bug de tres caracteres en el kernel que inflaba el contador Committed_AS hasta 651 GB en un equipo de 8 GB. Se muestra cómo diagnosticarlo con /proc/meminfo, ps y los VmFlags de /proc//smaps, y por qué las hugepages quedaron descartadas como origen antes de localizar la fuga en la contabilidad de memoria virtual.