Protege tus aplicaciones críticas del OOM Killer de Linux: cinco comandos imprescindibles

Tu base de datos desaparece cada noche y la única pista es una línea del kernel que dice Out of memory: Killed process. Aquí tienes cómo protegerla con choom, OOMScoreAdjust, MemoryMax, un archivo de swap y systemd-oomd.

Imagina que revisas un servidor por la mañana y descubres que MariaDB se detuvo a las 2:00, aunque nada cambió en su configuración. El servicio se reinicia sin problemas, los logs de MariaDB no muestran nada útil y, unas noches después, vuelve a pasar.

Cuando por fin miras el log del kernel, descubres que el OOM killer de Linux (Out-Of-Memory killer) terminó el proceso de la base de datos porque el servidor se quedó sin RAM.

Lo que hace esto confuso es que MariaDB no era el programa que consumió la memoria. Un worker de PHP, un script desbocado o un trabajo de backup pidieron más memoria de la que el servidor tenía, y el kernel eligió el proceso más grande que pudo encontrar para liberar memoria rápido, que en la mayoría de servidores es la base de datos.

La reacción habitual es añadir más RAM o reiniciar servicios con un cron, pero ninguna de las dos cosas cambia cómo el kernel elige a su víctima. La buena noticia es que Linux te da control directo sobre esa elección, y en esta guía usaremos cinco comandos para decidir qué proceso muere, limitar los programas que causan el problema y dar al servidor margen suficiente para recuperarse antes de que el OOM killer sea necesario.

¿Cómo el OOM Killer de Linux elige qué proceso matar?

Antes de cambiar nada, conviene entender cómo decide el kernel, porque cada comando de esta guía ajusta una parte de esa decisión.

Cuando el kernel no puede liberar suficiente memoria soltando caché o moviendo páginas a swap, tiene que terminar un proceso para mantener vivo el sistema. Calcula una puntuación de “maldad” para cada proceso, basada sobre todo en cuánta RAM y swap está usando, y mata el proceso con la puntuación más alta.

Puedes leer la puntuación actual de cualquier proceso en /proc/<pid>/oom_score, donde un número mayor significa que el proceso tiene más probabilidades de ser eliminado.

El kernel también te deja ajustar esa puntuación mediante un segundo archivo, /proc/<pid>/oom_score_adj, que acepta valores entre -1000 y 1000. Un valor positivo convierte al proceso en un objetivo más atractivo, un valor negativo lo protege, y -1000 le dice al kernel que nunca mate ese proceso.

Hay una pieza más que importa en las distribuciones modernas. Ubuntu 26.04 y Rocky Linux 10 usan cgroups v2 (grupos de control, la característica del kernel que systemd usa para agrupar y limitar los procesos de cada servicio), lo que significa que puedes dar a cada servicio su propio límite de memoria.

Cuando un servicio alcanza su propio límite, el kernel ejecuta el OOM killer solo dentro de ese servicio, así que el resto del servidor queda intacto.

Confirma que el OOM Killer está matando tus aplicaciones

Ahora que sabes qué mira el OOM killer, el primer trabajo es confirmar que realmente es la causa de que tu servicio se detuviera, ya que un crash, un health check fallido o un reinicio manual pueden parecer similares desde fuera.

El kernel escribe cada evento OOM en su log, así que busca en los mensajes del kernel del journal de systemd tanto la línea que inicia el OOM killer como la que nombra el proceso eliminado:

sudo journalctl -k -g 'oom-killer|Killed process'

Salida de ejemplo:

Oct 21 02:14:07 tecmint kernel: php-fpm8.3 invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0
Oct 21 02:14:07 tecmint kernel: Out of memory: Killed process 1187 (mariadbd) total-vm:2457316kB, anon-rss:1201344kB, file-rss:0kB, shmem-rss:0kB, UID:107 pgtables:2876kB oom_score_adj:0

Estas dos líneas cuentan toda la historia. La primera muestra que php-fpm8.3 pidió memoria que no estaba disponible, y la segunda muestra que el kernel mató a mariadbd en su lugar, porque estaba usando unos 1,2 GB de RAM (el valor anon-rss) y tenía la puntuación más alta.

💡 La opción -k limita la salida a los mensajes del kernel del arranque actual. Si el servidor se reinició desde el evento, añade -b -1 para mirar el arranque anterior.

En sistemas sin journal persistente, las mismas líneas están disponibles en el buffer de anillo del kernel hasta el siguiente reinicio:

sudo dmesg -T | grep -iE 'oom-killer|killed process'

Antes de proteger nada, es útil ver qué procesos elegiría el kernel ahora mismo. El siguiente bucle imprime la puntuación OOM, el valor de ajuste y el nombre del proceso para cada proceso en ejecución, y luego muestra los cinco candidatos más probables:

for p in /proc/[0-9]*; do
  printf '%s %s %s\n' \
    "$(cat $p/oom_score 2>/dev/null)" \
    "$(cat $p/oom_score_adj 2>/dev/null)" \
    "$(cat $p/comm 2>/dev/null)"
done | sort -rn | head -5

Salida de ejemplo:

668 0 mariadbd
141 0 php-fpm8.3
139 0 php-fpm8.3
42 0 node
12 0 systemd-journal

Tus números serán distintos, porque dependen de cuánta memoria use cada proceso en tu servidor. Lo que importa es el orden, porque el proceso en la cima de esta lista es el que será eliminado a continuación y, en nuestro caso, sigue siendo la base de datos.

Comprueba y cambia la prioridad OOM de un proceso con choom

Como la base de datos está en la cima de la lista, el arreglo más rápido es bajar su prioridad mientras sigue en ejecución, y el comando choom del paquete util-linux hace exactamente eso. Está instalado por defecto tanto en Ubuntu como en Rocky Linux, así que no hay que añadir nada.

Empieza comprobando los valores actuales del proceso de MariaDB:

choom -p $(pidof mariadbd)

pid 1187's current OOM score: 668
pid 1187's current OOM score adjust value: 0

Ahora baja el valor de ajuste a -500. Bajar un valor requiere root, porque de lo contrario cualquier usuario podría hacer sus propios procesos inmunes al OOM killer:

sudo choom -p $(pidof mariadbd) -n -500

pid 1187's OOM score adjust value changed from 0 to -500

Si vuelves a ejecutar el primer comando choom, la puntuación OOM será mucho menor, y los workers de PHP u otro proceso grande estarán ahora por delante de MariaDB en la lista.

choom también funciona en la dirección opuesta, lo que a menudo es más útil que proteger un solo servicio. Cuando lanzas un trabajo por lotes, un informe o un script puntual que puedes volver a ejecutar con seguridad, puedes subir su valor para que el kernel lo elija primero. Subir un valor no requiere root:

choom -n 500 -- ./generate-monthly-report.sh

⚠️ Limitación importante: el valor que establece choom pertenece al proceso en ejecución, así que se pierde en cuanto MariaDB se reinicia o el servidor se reinicia. Por eso el siguiente paso hace el cambio permanente.

Protege un servicio de forma permanente con OOMScoreAdjust

El cambio de choom desaparece en el siguiente reinicio, así que para un servicio gestionado por systemd, el lugar correcto para esta configuración es la propia unidad del servicio. systemd tiene una directiva llamada OOMScoreAdjust que establece el mismo valor cada vez que arranca el servicio.

Primero, comprueba si la unidad de MariaDB ya establece un valor, ya que algunos paquetes incluyen uno:

systemctl show mariadb -p OOMScoreAdjust

OOMScoreAdjust=0

En lugar de editar el archivo de unidad empaquetado (que una actualización del paquete sobrescribiría), crea un drop-in override con systemctl edit. Este comando abre un editor automáticamente, usando nano en Ubuntu y recurriendo a vi en instalaciones mínimas de Rocky Linux donde nano no está instalado:

sudo systemctl edit mariadb

Añade la siguiente configuración en el área vacía entre las líneas de comentario de la parte superior del archivo:

# /etc/systemd/system/mariadb.service.d/override.conf
[Service]
OOMScoreAdjust=-500

Aquí:

• [Service] le dice a systemd que las directivas siguientes pertenecen a la sección de servicio de la unidad.
• OOMScoreAdjust=-500 escribe -500 en oom_score_adj para cada proceso que arranca el servicio, lo que convierte a MariaDB en un objetivo mucho menos probable sin hacerlo completamente inmune.

Guarda el archivo y sal del editor. systemctl edit recarga systemd por ti, pero el nuevo valor solo se aplica cuando el proceso del servicio arranca, así que reinicia MariaDB en un momento tranquilo:

sudo systemctl restart mariadb

Cuando vuelva a estar arriba, confirma que tanto systemd como el kernel ven el nuevo valor:

systemctl show mariadb -p OOMScoreAdjust
cat /proc/$(pidof mariadbd)/oom_score_adj

OOMScoreAdjust=-500
-500

⚠️ No uses -1000 a la ligera. Puede tentarte hacer la base de datos imposible de matar, pero evítalo salvo que estés seguro de que el servicio protegido nunca puede ser el que consume demasiada memoria. Si lo es, el kernel matará primero a todos los demás procesos del servidor y puede quedarse sin nada que matar.

En ese caso el kernel registra Out of memory and no killable processes… y entra en panic, lo que convierte un servicio detenido en una caída total del servidor.

Limita los servicios devoradores de memoria con MemoryHigh y MemoryMax

Proteger la base de datos traslada el problema al siguiente proceso de la lista, pero la causa real sigue siendo la aplicación que no deja de crecer. El arreglo mejor es darle a esa aplicación su propio límite de memoria, de modo que cuando crezca demasiado, el kernel se encargue de ella dentro de su propio cgroup y nunca toque el resto del servidor.

Esto se apoya en cgroups v2, que Ubuntu 26.04 y Rocky Linux 10 usan por defecto. Puedes confirmarlo rápidamente antes de establecer cualquier límite:

stat -fc %T /sys/fs/cgroup

cgroup2fs

Con eso confirmado, establece dos límites en el servicio de la aplicación usando systemctl set-property. Usaremos myapp.service como ejemplo, así que reemplázalo por el nombre de tu propia aplicación (un servicio de Gunicorn, Node.js o PHP-FPM, por ejemplo):

sudo systemctl set-property myapp.service MemoryHigh=1.5G MemoryMax=2G

Aquí:

• MemoryHigh=1.5G es un límite blando. Cuando el servicio lo supera, el kernel lo frena y recupera su memoria de forma agresiva, lo que a menudo mantiene a raya una aplicación con fugas sin matarla.
• MemoryMax=2G es el límite duro. Si el servicio aun así llega a 2 GB, el kernel ejecuta el OOM killer solo sobre los procesos de este servicio, así que MariaDB y todo lo demás siguen funcionando.

El cambio surte efecto inmediatamente sin reiniciar el servicio, y se mantiene tras un reinicio, porque systemctl set-property lo guarda en /etc/systemd/system.control/myapp.service.d/. Si solo quieres probar un límite hasta el siguiente reinicio, añade la opción --runtime.

Puedes comprobar los límites activos con systemctl show, que los reporta en bytes:

systemctl show myapp -p MemoryHigh -p MemoryMax

MemoryHigh=1610612736
MemoryMax=2147483648

Elige los valores observando primero el uso normal de memoria del servicio. systemctl status myapp muestra el uso actual en su línea Memory:, y un punto de partida sensato es poner MemoryHigh un poco por encima del pico habitual y MemoryMax algo más arriba.

Prueba un límite de memoria con un evento OOM deliberado

Antes de confiar en estos límites, merece la pena ver uno funcionar, porque el resultado en los logs se ve muy distinto del evento OOM global que encontramos antes. El siguiente comando arranca un servicio temporal con un límite de 200 MB y ejecuta tail /dev/zero, que sigue leyendo datos sin encontrar nunca un final de línea, así que su uso de memoria crece hasta que algo lo detiene:

sudo systemd-run --unit=oomtest -p MemoryMax=200M -p MemorySwapMax=0 tail /dev/zero

La propiedad MemorySwapMax=0 impide que la prueba empuje su memoria a swap, así que el límite se alcanza en uno o dos segundos. Ahora comprueba qué le pasó al servicio de prueba:

journalctl -u oomtest --no-pager

Oct 22 11:02:41 tecmint systemd[1]: Started oomtest.service - /usr/bin/tail /dev/zero.
Oct 22 11:02:43 tecmint systemd[1]: oomtest.service: A process of this unit has been killed by the OOM killer.
Oct 22 11:02:43 tecmint systemd[1]: oomtest.service: Main process exited, code=killed, status=9/KILL
Oct 22 11:02:43 tecmint systemd[1]: oomtest.service: Failed with result 'oom-kill'.

El log del kernel confirma que este fue un evento OOM de cgroup y no uno de todo el servidor, porque el mensaje empieza con Memory cgroup out of memory en lugar de solo Out of memory:

sudo journalctl -k -g 'Memory cgroup out of memory'

Oct 22 11:02:43 tecmint kernel: Memory cgroup out of memory: Killed process 4821 (tail) total-vm:207604kB, anon-rss:203796kB, file-rss:4kB, shmem-rss:0kB, UID:0 pgtables:448kB oom_score_adj:0

Solo tail fue eliminado, aunque MariaDB es un proceso mucho más grande. Una vez visto el resultado, limpia la unidad de prueba fallida para que no aparezca en systemctl --failed:

sudo systemctl reset-failed oomtest

Da margen de respiración al kernel con swapon

Con los límites en su sitio, el riesgo restante es un pico breve que ningún servicio causa por sí solo, como un backup, una actualización de paquetes y el tráfico normal coincidiendo a la vez.

El OOM killer solo se ejecuta cuando el kernel no tiene otra forma de liberar memoria, y el swap le da otra vía: puede mover páginas de memoria usadas con poca frecuencia al disco en lugar de matar un proceso.

Muchas imágenes de nube y VMs mínimas no traen swap, así que comprueba primero qué tiene el servidor:

swapon --show
free -h

Si swapon --show no imprime nada, el servidor no tiene swap. Las instalaciones de Ubuntu Server suelen crear un archivo /swap.img, y las de Rocky Linux con el layout LVM por defecto suelen crear un volumen de swap, así que solo necesitas los pasos siguientes si tu servidor no tiene nada o muy poco.

Crea un archivo de swap de 2 GB con dd, que escribe bloques reales a disco y funciona tanto en ext4 como en XFS. Luego bloquea sus permisos, ya que el swap puede contener contraseñas y otros datos de la memoria, formatéalo como swap y actívalo:

sudo dd if=/dev/zero of=/swapfile bs=1M count=2048 status=progress
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

💡 Si tu sistema de archivos raíz es Btrfs, un archivo de swap normal no funcionará y swapon fallará con Invalid argument. En ese caso crea el archivo con sudo btrfs filesystem mkswapfile --size 2g /swapfile en lugar de dd, y continúa desde swapon.

El archivo de swap solo permanece activo hasta el siguiente reinicio, así que añádelo a /etc/fstab. En Ubuntu y Debian, abre el archivo con nano:

sudo nano /etc/fstab

En Rocky Linux, AlmaLinux y RHEL, las instalaciones mínimas traen vi en lugar de nano, así que usa vi allí:

sudo vi /etc/fstab

Luego añade la siguiente línea al final del archivo:

# /etc/fstab
/swapfile none swap defaults 0 0

Guarda el archivo y sal del editor, y confirma que el archivo de swap está activo:

swapon --show

NAME      TYPE SIZE USED PRIO
/swapfile file   2G   0B   -2

⚠️ El swap no arregla una fuga de memoria. Solo le da al kernel más tiempo, y un servidor que depende mucho del swap se vuelve muy lento mucho antes de que el OOM killer se ejecute, que es exactamente la situación que el último comando está diseñado para manejar.

¿Cómo detener la presión de memoria antes con systemd-oomd y oomctl?

El OOM killer del kernel actúa en el último momento posible, así que un servidor puede pasar varios minutos casi congelado mientras hace swap y recupera memoria antes de que se mate nada.

systemd-oomd es un demonio OOM en espacio de usuario que vigila la presión de memoria en su lugar, y termina el servicio adecuado mucho antes, mientras el servidor sigue respondiendo.

Mide la presión con PSI (Pressure Stall Information), una característica del kernel que reporta el porcentaje de tiempo que los procesos pasan esperando memoria. Comprueba que PSI está disponible en tu servidor:

cat /proc/pressure/memory

some avg10=0.00 avg60=0.00 avg300=0.00 total=0
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

⚠️ En Rocky Linux y RHEL, este comando puede fallar con cat: /proc/pressure/memory: Operation not supported, porque PSI está deshabilitado por defecto en sus kernels, incluido RHEL 10. Actívalo añadiendo un argumento de arranque al kernel y reiniciando el servidor:

sudo grubby --update-kernel=ALL --args="psi=1"
sudo reboot

A continuación, instala y arranca el demonio. En Ubuntu, systemd-oomd se proporciona como paquete separado, y las instalaciones de servidor pueden no incluirlo por defecto:

sudo apt install systemd-oomd
sudo systemctl enable --now systemd-oomd

En Rocky Linux, AlmaLinux y RHEL, instala systemd-oomd con dnf y habilita el servicio. El paquete está disponible en los repositorios de Rocky Linux 10 y AlmaLinux 10; verifica la disponibilidad en tus repositorios RHEL habilitados:

sudo dnf install systemd-oomd
sudo systemctl enable --now systemd-oomd

systemd-oomd solo vigila los cgroups que le indiques. Le pediremos que vigile system.slice, que es el cgroup padre de todos los servicios del sistema, para que pueda elegir el servicio que causa la presión. Abre un drop-in para el slice:

sudo systemctl edit system.slice

Añade la siguiente configuración:

# /etc/systemd/system/system.slice.d/override.conf
[Slice]
ManagedOOMMemoryPressure=kill
ManagedOOMMemoryPressureLimit=60%

• ManagedOOMMemoryPressure=kill le dice a systemd-oomd que vigile este slice y mate uno de los servicios de su interior cuando la presión de memoria se mantenga demasiado alta.
• ManagedOOMMemoryPressureLimit=60% establece el umbral de presión de memoria. Si la presión supera el 60% durante más tiempo que la duración configurada, systemd-oomd puede actuar. La duración por defecto la controla DefaultMemoryPressureDurationSec en /etc/systemd/oomd.conf y suele ser de 30 segundos, según la versión de systemd.

Guarda el archivo y sal del editor. Cuando systemd-oomd actúa, elige el servicio con más actividad de recuperación de memoria, que suele ser el que está creciendo, pero aún puedes mantener a MariaDB fuera de sus primeras opciones. Abre el mismo override de MariaDB que creamos en la sección anterior:

sudo systemctl edit mariadb

Luego añade una línea más bajo la configuración existente de OOMScoreAdjust:

# /etc/systemd/system/mariadb.service.d/override.conf
[Service]
OOMScoreAdjust=-500
ManagedOOMPreference=avoid

ManagedOOMPreference=avoid le dice a systemd-oomd que elija otros servicios antes que este. El otro valor aceptado, omit, elimina el servicio de la consideración por completo, y ambos solo funcionan para servicios cuyo cgroup es propiedad de root, que es el caso de los servicios de sistema normales.

Guarda el archivo y sal del editor, y reinicia MariaDB para que la preferencia se aplique a su nuevo cgroup:

sudo systemctl restart mariadb

Ahora oomctl muestra qué está vigilando systemd-oomd y la presión actual de cada cgroup:

oomctl

La salida se parecerá a la siguiente, aunque el diseño exacto depende de tu versión de systemd:

Dry Run: no
Swap Used Limit: 90.00%
Default Memory Pressure Limit: 60.00%
Default Memory Pressure Duration: 30s
System Context:
        Memory: Used: 1.4G Total: 3.8G
        Swap: Used: 0B Total: 2.0G
Swap Monitored CGroups:
Memory Pressure Monitored CGroups:
        Path: /system.slice
                Memory Pressure Limit: 60.00%
                Pressure: Avg10: 0.00 Avg60: 0.00 Avg300: 0.00 Total: 0
                Current Memory Usage: 1.1G

💡 Si /system.slice no aparece en Memory Pressure Monitored CGroups, el drop-in no se recogió: ejecuta sudo systemctl daemon-reload y vuelve a comprobar.

Cuando systemd-oomd sí mata un servicio, registra su propio mensaje en lugar de uno del kernel, así que busca en su journal en vez de en el log del kernel:

journalctl -u systemd-oomd

Un kill aparece como una línea que empieza por Killed /system.slice/ seguida del nombre del servicio y la presión que lo desencadenó, y el servicio afectado falla con el mismo resultado oom-kill que vimos en la prueba anterior.

Consejos profesionales para mantener callado al OOM Killer

Con los cinco comandos en su sitio, el OOM killer tiene ahora instrucciones claras, y unos cuantos hábitos ayudan a que ni siquiera las necesite.

Haz que la aplicación vuelva sola. Como MemoryMax ahora solo mata a la aplicación que se porta mal, asegúrate de que esa aplicación se recupera por sí misma. Añade Restart=on-failure y RestartSec=5 a su unidad con sudo systemctl edit myapp, para que un único kill del OOM se convierta en un reinicio de cinco segundos en lugar de una caída que espera a que alguien la note.

Cuidado con vm.overcommit_memory=2. Puedes encontrar en internet el consejo de poner vm.overcommit_memory=2 para que el kernel rechace peticiones de memoria que no pueda cubrir. Ten cuidado, porque muchas aplicaciones reservan mucha más memoria de la que usan, y con overcommit estricto empiezan a fallar con errores Cannot allocate memory incluso cuando el servidor tiene RAM libre. Rara vez es la respuesta correcta en un servidor de propósito general, y los límites de cgroup de la sección anterior te dan la misma protección servicio a servicio.

Ejecuta solo un demonio OOM en espacio de usuario. Herramientas como earlyoom hacen un trabajo similar a systemd-oomd, y ejecutar ambos significa dos programas compitiendo por matar procesos bajo la misma presión, lo que hace el resultado difícil de predecir.

Trata cada evento OOM como una señal, no como algo que ocultar. Proteger la base de datos mantiene el sitio en línea esta noche, pero si journalctl -k -g 'Killed process' sigue devolviendo líneas nuevas, el servidor necesita o un arreglo para la aplicación con fugas o más memoria.

Conclusión

Ahora puedes averiguar exactamente qué proceso detuvo el OOM killer y por qué, proteger servicios importantes con choom y OOMScoreAdjust, y contener aplicaciones que crecen con MemoryHigh y MemoryMax.

Con un archivo de swap para picos cortos y systemd-oomd vigilando la presión de memoria, el servidor maneja la memoria baja antes y en tus términos, en lugar de perder la base de datos a las 2:00 de la madrugada.

💡 Siguiente paso: si quieres ir más allá y leer el comportamiento de memoria, CPU y disco antes de que se convierta en un evento OOM, explora herramientas como top, htop, vmstat, iostat y sar, que te muestran la presión acumulándose mucho antes de que el kernel tenga que actuar.

🎁 Anexo: mejoras y actualizaciones sugeridas en esta versión

Añadidas a esta traducción, fruto del análisis del artículo original:

• Restart=on-failure + RestartSec=5 destacado como primer paso práctico: sin él, MemoryMax te salva del caos global pero deja el servicio caído esperando intervención manual.
• Advertencia explícita sobre -1000 con el escenario de kernel panic (Out of memory and no killable processes…), que el original menciona pero conviene leer antes de aplicar.
• Nota sobre Btrfs y swap ampliada con el comando exacto btrfs filesystem mkswapfile para no perder tiempo depurando Invalid argument.
• Rutas de unidad de systemd: se aclara que el drop-in va en /etc/systemd/system/<servicio>.service.d/override.conf (no en /etc/systemd/system.control/, que es donde vive set-property), para evitar confusión entre ambos mecanismos.
• ManagedOOMPreference=omit explicado además de avoid, porque es útil cuando un servicio nunca debe ser la víctima de systemd-oomd.
• Diagnóstico de drop-ins no aplicados: recordatorio de ejecutar systemctl daemon-reload antes de concluir que oomctl no ve el slice.
• Separación clara entre OOM global y OOM de cgroup en los logs (Out of memory vs Memory cgroup out of memory), que es la pista que confirma que tus límites están haciendo su trabajo.
• Orden recomendado de aplicación: primero diagnosticar (journalctl -k), luego proteger (choom/OOMScoreAdjust), luego limitar (MemoryHigh/MemoryMax), luego dar margen (swap) y por último anticipar (systemd-oomd). Aplicar los cinco a la vez sin medir antes hace imposible saber qué cambio funcionó.