Si administras un servidor Linux, despertar y descubrir que tu proceso crítico de base de datos o servidor web está muerto inesperadamente es una pesadilla. Frecuentemente, el culpable es el Out of Memory (OOM) Killer, un componente despiadado pero necesario del kernel de Linux. Esta guía explica por qué ataca el OOM Killer, cómo diagnosticar definitivamente un evento OOM y cómo configurar tu sistema para evitar que paralice tu infraestructura.

¿Qué es el OOM Killer?

Cuando un sistema Linux se queda completamente sin RAM física y espacio de Swap, se enfrenta a un congelamiento total del sistema. Para evitar esto, el kernel invoca al OOM Killer.

El OOM Killer examina todos los procesos en ejecución, calcula una puntuación de “maldad” (oom_score) basada principalmente en el uso de la memoria, y luego termina violentamente (SIGKILL) el proceso con la puntuación más alta para liberar memoria instantáneamente y salvar el sistema.

El Error: Cómo atrapar al OOM Killer en acción

Debido a que el OOM Killer opera a nivel del kernel, tu aplicación rara vez tiene tiempo de escribir un error en su propio archivo de registro. En su lugar, el proceso simplemente desaparece.

Para confirmar una muerte por OOM, debes revisar los registros del kernel. Ejecuta:

dmesg -T | grep -i "Out of memory"

O, para ver exactamente qué proceso fue asesinado:

dmesg -T | egrep -i "killed process"

Verás una salida parecida a esta:

[Fri Feb 27 10:15:30 2026] Out of memory: Killed process 12345 (mysqld) total-vm:4567890kB, anon-rss:3456780kB, file-rss:0kB, shmem-rss:0kB, UID:111 pgtables:8000kB oom_score_adj:0

Causa del problema: ¿Por qué ocurrió?

El OOM Killer solo ataca cuando el sistema está hambriento de memoria. Los escenarios comunes incluyen:

  1. Una fuga de memoria (Memory Leak): Una aplicación con errores (a menudo código personalizado o lenguajes como Java o Node.js sin límites adecuados) consume lentamente RAM con el tiempo hasta que el servidor se agota.
  2. Pico repentino de tráfico: Una ráfaga de tráfico web generó demasiados procesos de trabajo PHP-FPM o Apache, aumentando exponencialmente el uso de la memoria.
  3. Configuración incorrecta de la base de datos: Una base de datos como MySQL está configurada para usar más memoria (por ejemplo, innodb_buffer_pool_size) de la que el servidor posee físicamente.
  4. Sin espacio de Swap: El servidor tiene exactamente 0 bytes de Swap configurados, dejando al kernel sin red de seguridad cuando la RAM se llena.

Solución Paso a Paso

Paso 1: Añadir o Incrementar Espacio de Swap

Si tu servidor no tiene espacio de swap, agregar incluso una pequeña cantidad puede absorber picos repentinos y temporales en el uso de memoria y darte tiempo para reaccionar antes de que actúe el OOM Killer.

Crea un archivo swap de 2GB:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Hazlo permanente añadiéndolo a /etc/fstab:

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Paso 2: Optimizar la Configuración de las Aplicaciones

Si MySQL o PostgreSQL es asesinado constantemente, es probable que esté mal configurado. Revisa la configuración de tu base de datos (por ejemplo, /etc/mysql/my.cnf) y asegúrate de que los buffers tengan el tamaño adecuado para tu hardware. Una regla común para innodb_buffer_pool_size es el 50-70% de la RAM total, pero si ejecutas un servidor web en la misma máquina, debe ser significativamente menor.

Para PHP/Apache/Nginx: Reduce el número máximo de procesos worker o procesos secundarios permitidos para generarse simultáneamente.

Paso 3: Manipular la Puntuación OOM (Protección de Procesos Críticos)

Cada proceso tiene un valor oom_score_adj que va de -1000 a 1000. Cuanto mayor sea el número, más probable es que el OOM Killer lo tome como objetivo. Un valor de -1000 hace que el proceso sea inmune.

Si tienes un proceso crítico (como sshd para que siempre puedas iniciar sesión, o un demonio central) que absolutamente no puedes perder, puedes ajustar su puntuación.

Primero, encuentra el PID del proceso (por ejemplo, PID 1234).

echo -500 > /proc/1234/oom_score_adj

(Necesitarás un script para hacer esto automáticamente tras el reinicio del proceso, o usar systemd).

Usando Systemd (La Mejor Forma): Si el proceso es administrado por systemd, puedes configurar la puntuación OOM de forma nativa. Edita el archivo de servicio (por ejemplo, sudo systemctl edit sshd):

[Service]
OOMScoreAdjust=-1000

Luego ejecuta sudo systemctl daemon-reload y reinicia el servicio.

Paso 4: Evitar el Overcommit del Kernel

Por defecto, Linux permite a las aplicaciones solicitar más memoria de la que realmente tiene el sistema (Memory Overcommit). Asume que no todas las aplicaciones usarán lo que solicitan. Cuando realmente lo usan, se produce un evento OOM.

Puedes restringir este comportamiento a través de sysctl:

sudo sysctl -w vm.overcommit_memory=2
sudo sysctl -w vm.overcommit_ratio=80

Esto le dice al kernel que no permita asignación de memoria superior a (Swap + 80% de RAM). Añade esto a /etc/sysctl.conf para que persista tras reiniciar.

Prevención

Para mantener a raya permanentemente al OOM Killer:

  • Implementar Alertas: Configura herramientas (Prometheus, Datadog) o scripts de Monit simples para alertarte cuando el uso de la memoria supere el 85%.
  • Configurar Cgroups: Si ejecutas Docker o Kubernetes, establece límites de memoria estrictos en los contenedores (--memory="512m"). Si un proceso dentro del contenedor se descontrola, el OOM Killer solo matará el contenedor, dejando el sistema anfitrión completamente ileso.
  • Dimensionar Correctamente el Servidor: A veces, no hay solución de software para la falta de hardware. Si su aplicación principal legítimamente requiere 8GB de RAM para ejecutarse eficientemente y usted está en un VPS de 4GB, debe actualizar (upgrade) la memoria física en el centro de datos.

Resumen

  • El Linux OOM Killer es un mecanismo de defensa del kernel subyacente que mata el proceso que consume más memoria para evitar que un sistema que padece inanición absoluta de recursos se congele globalmente.
  • Diagnosticar un evento OOM requiere verificar el búfer de anillo del kernel (kernel ring buffer) utilizando dmesg.
  • Prevenga muertes por OOM configurando el espacio de Swap, ajustando los límites de memoria de la aplicación (como los tamaños del búfer de MySQL) y estableciendo límites estrictos a través de cgroups o systemd.
  • Puede proteger a los demonios críticos bajando su valor OOMScoreAdjust directamente a través de systemd en el archivo de inicio nativo.

Artículos Relacionados