Cómo interpretar la presión de memoria en Linux: free, swap, el OOM killer y OOMScoreAdjust

Qué es

free muestra la memoria total, usada, libre (free), compartida (shared), buff/cache y disponible (available), además de una línea de swap. La columna free por sí sola subestima el margen disponible, porque Linux aprovecha la memoria que no está en uso como cache de disco; la columna available estima cuánta memoria se puede asignar realmente a un proceso nuevo sin recurrir al swap, teniendo en cuenta la cache recuperable. Cuando se agotan tanto la memoria disponible como el swap, el OOM killer (out-of-memory) del kernel elige un proceso y lo termina para mantener el sistema en funcionamiento, y registra su acción en el log del kernel, visible con dmesg o journalctl -k.

Dos opciones de las unidades de systemd influyen en este comportamiento para cada servicio: OOMScoreAdjust=, un valor de -1000 a 1000 que se escribe en /proc/[pid]/oom_score_adj y que inclina la heurística OOM del kernel a favor o en contra de terminar ese proceso (cuanto más negativo, menos probable es que sea elegido); y MemoryMax=, un límite estricto aplicado por el controlador de cgroups, que hace que un proceso sea terminado por superar su propio presupuesto antes de que el OOM killer del sistema tenga que elegir entre servicios que no guardan relación entre sí.

Por qué importa

Un servicio que muere sin ningún error a nivel de aplicación y sin log de fallo es un síntoma habitual de una terminación por OOM: el kernel lo termina con SIGKILL, que la aplicación no puede capturar ni registrar. Confundirlo con un bug de la aplicación hace perder tiempo de depuración; confundir la memoria free con la memoria available provoca falsas alarmas o hace pasar por alto alarmas reales.

Cómo aplicarlo

• Lee free -h y guíate por available, no por free; un valor pequeño de free con un valor grande de available es normal y no supone ningún problema.
• Comprueba el uso de swap y si hay swap configurado siquiera (swapon --show); un sistema sin swap dispone de menos tiempo de aviso antes de que actúe el OOM killer.
• Tras la muerte inexplicada de un servicio, busca con journalctl -k | grep -i "out of memory" o dmesg | grep -i oom un registro de terminación que nombre el proceso y su puntuación.
• Define OOMScoreAdjust=-500 (o un valor similar) en la sección [Service] de una unidad de systemd para un proceso que debe ser el último en ser terminado, y un valor positivo para un trabajo por lotes prescindible que deba ir primero.
• Define MemoryMax= en los servicios cuyo consumo máximo de memoria conoces, de modo que una fuga en uno de ellos no deje sin memoria a otros servicios no relacionados del mismo host; verifícalo con systemctl show <unit> -p MemoryMax -p OOMScoreAdjust.

Trampas

• Tratar cualquier muerte de proceso como un bug de código antes de buscar un registro de OOM en el log del kernel.
• Configurar OOMScoreAdjust=-1000 (en la práctica, inmune al OOM killer) en un servicio, que así oculta una fuga real al trasladar la terminación a otro proceso en lugar de hacer visible el problema.
• Olvidar que MemoryMax= provoca una terminación OOM a nivel de cgroup de los propios procesos del servicio, que en dmesg se ve idéntica a una terminación OOM del sistema entero, pero tiene una causa distinta y más acotada.