El OOM Killer (Out-Of-Memory Killer) es un componente del kernel Linux que, cuando la memoria RAM disponible se agota por completo, elige y termina procesos para liberar memoria y evitar que el sistema se cuelgue. Si encuentras en tus logs líneas como Killed process 1234 (php-fpm), fue el OOM Killer el responsable.
Esta guía explica cómo detectar que el OOM Killer actuó, por qué ocurre con más frecuencia en VPS (donde la RAM es limitada y compartida), y qué medidas concretas evitan que elimine tus procesos críticos.
Cómo funciona el OOM Killer
Linux utiliza un sistema de asignación de memoria optimista: permite que los procesos reserven más RAM de la que físicamente existe, asumiendo que nunca la usarán toda a la vez. Esto se llama overcommit. Cuando la suposición falla — varios procesos reclaman su memoria al mismo tiempo — el kernel entra en crisis de OOM.
En ese momento el kernel calcula una puntuación (oom_score) para cada proceso en función de cuánta memoria usa, cuánto tiempo lleva corriendo y si está marcado como "sacrificable". El proceso con mayor puntuación muere primero.
El resultado típico en un VPS mal dimensionado o mal configurado:
- MySQL o MariaDB muere en plena noche y el sitio web cae.
- PHP-FPM es eliminado y todas las páginas devuelven error 502.
- Un proceso de respaldo consume RAM extra y derriba la aplicación principal.
Cómo detectar que el OOM Killer actuó
El kernel registra cada intervención del OOM Killer en el log del sistema. Búscalo así:
# Método moderno (systemd)
sudo journalctl -k | grep -i "oom\|killed process"
# Método clásico
sudo dmesg | grep -i "oom\|killed process"
# En distros con /var/log/kern.log
sudo grep -i "oom\|killed" /var/log/kern.log | tail -50Un evento típico en los logs se ve así:
kernel: Out of memory: Kill process 8423 (mysql) score 247 or sacrifice child
kernel: Killed process 8423 (mysql) total-vm:512MB, anon-rss:320MBVerás el proceso eliminado, su PID, la puntuación OOM y cuánta memoria usaba. Guarda esa información: te dirá exactamente qué proceso fue el detonante.
Causas comunes en un VPS
Los VPS tienen RAM fija y —a diferencia de un servidor dedicado— sin swap por defecto en muchos proveedores. Las causas más frecuentes de agotamiento de memoria son:
| Causa | Ejemplo práctico |
|---|---|
| VPS subdimensionado | 2 GB de RAM para MySQL + PHP-FPM + Redis + cron jobs |
| MySQL/MariaDB mal configurado | innodb_buffer_pool_size al 70-80 % de la RAM total |
| PHP-FPM con demasiados workers | pm.max_children = 50 en un VPS de 1 GB |
| Sin archivo swap | Cuando la RAM se llena no hay colchón de emergencia |
| Fugas de memoria | Plugin de WordPress o script que acumula RAM sin liberarla |
| Pico de tráfico | Viral o ataque DDoS multiplica las peticiones simultáneas |
Cómo evitar que el OOM Killer actúe
1. Añade swap como colchón de emergencia
El swap es lento (disco vs. RAM), pero es un salvavidas cuando la memoria física se agota momentáneamente. En un VPS SSD/NVMe la penalización es tolerable para picos cortos.
# Crea un archivo de 2 GB de swap
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
# Hazlo permanente en /etc/fstab
echo "/swapfile swap swap defaults 0 0" | sudo tee -a /etc/fstabAjusta también la tendencia del kernel a usar swap (swappiness). En servidores, un valor bajo es mejor:
# Valor temporal (desaparece al reiniciar)
sudo sysctl vm.swappiness=10
# Valor permanente
echo "vm.swappiness=10" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p2. Ajusta los límites de memoria de tus servicios
Configura cada servicio para que use solo lo que puede permitirse. Para MySQL/MariaDB en un VPS de 2 GB:
# /etc/mysql/mariadb.conf.d/99-tuning.cnf
[mysqld]
innodb_buffer_pool_size = 512M # no más del 25-30 % de la RAM total
key_buffer_size = 32M
max_connections = 50Para PHP-FPM, calcula cuántos workers caben. Si cada worker de PHP usa ~30 MB y tienes 1 GB disponible para PHP:
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 63. Protege procesos críticos con oom_score_adj
Puedes reducir la probabilidad de que el OOM Killer elija un proceso específico ajustando su puntuación. El rango va de -1000 (completamente inmune) a +1000 (primero en morir).
# Protege MySQL: busca el PID primero
pid=$(pgrep -x mysqld)
echo -500 | sudo tee /proc/$pid/oom_score_adjPara hacerlo permanente con systemd, añade a la unidad del servicio:
# /etc/systemd/system/mariadb.service.d/oom.conf
[Service]
OOMScoreAdjust=-500sudo systemctl daemon-reload
sudo systemctl restart mariadbEl valor -500 significa que el kernel necesita que el proceso esté usando mucha más memoria que otros antes de considerarlo candidato. No uses -1000 a menos que estés seguro: si el proceso tiene una fuga de memoria, el sistema entero se bloqueará.
4. Monitorea el uso de RAM en tiempo real
La prevención pasa por conocer el consumo antes de que explote:
# Resumen rápido
free -h
# Por proceso, ordenado por memoria
ps aux --sort=-%mem | head -20
# Monitor continuo
vmstat 2 10 # cada 2 segundos, 10 muestrasHerramientas como Netdata o Prometheus + Node Exporter envían alertas cuando la RAM supera un umbral antes de que el OOM Killer intervenga. Es la diferencia entre reaccionar y prevenir.
Para más estrategias de optimización del servidor, consulta los recursos de mantenimiento para VPS disponibles en nuestro blog.
5. Considera ampliar la RAM o migrar de plan
Si el OOM Killer actúa frecuentemente con la configuración ajustada, la señal es clara: el VPS está subdimensionado para la carga. Escalar a un plan con más RAM suele ser más económico que las horas de soporte y las caídas de servicio acumuladas.
Muchos proveedores permiten escalar RAM sin cambiar de IP ni reinstalar. En elenlace.com te ayudamos a elegir el plan correcto desde el principio, ahorrándote este tipo de problemas reactivos.
Conclusiones clave
- El OOM Killer mata procesos para salvar el sistema cuando la RAM se agota; no es un bug, es un mecanismo de emergencia del kernel.
- Los logs del kernel (
journalctl -kodmesg) revelan exactamente qué proceso fue eliminado y cuánta memoria usaba. - Añadir swap (incluso 1-2 GB) da un colchón que evita intervenciones del OOM Killer en picos cortos.
- Ajustar
innodb_buffer_pool_size, workers de PHP-FPM y otros límites por servicio es el cambio con mayor impacto. oom_score_adjpermite proteger procesos críticos de ser los primeros candidatos a muerte.- Si el problema persiste con todo ajustado, el VPS necesita más RAM o un rediseño de la arquitectura.
¿Tu VPS sigue sufriendo caídas por memoria? Escríbenos: en elenlace.com analizamos tu configuración y te proponemos un plan de acción concreto.
Preguntas frecuentes
¿El OOM Killer puede dañar mis datos?
Puede. Si el proceso eliminado era una base de datos en plena escritura, las tablas pueden quedar en estado inconsistente. MySQL/MariaDB incluye recuperación automática al reiniciar (InnoDB crash recovery), pero no es garantía absoluta. Los respaldos periódicos siguen siendo indispensables.
¿Cuánto swap debo añadir a mi VPS?
La regla clásica de "doble de la RAM" es excesiva para servidores modernos. Para un VPS de 1-4 GB de RAM, un swap de 1-2 GB es suficiente como colchón. Más swap no soluciona el problema de fondo: solo lo pospone y degrada el rendimiento si el sistema lo usa constantemente.
¿Es seguro poner OOMScoreAdjust=-1000 a MySQL?
No se recomienda. Con -1000 el proceso es completamente inmune al OOM Killer. Si MySQL tiene una fuga de memoria y acapara toda la RAM, el kernel no puede hacer nada y el sistema se bloqueará por completo. El valor -500 ofrece protección fuerte sin ese riesgo extremo.
¿Cómo sé si el OOM Killer actuó si el servidor se reinició?
Si el servidor se reinició abruptamente, revisa los logs del boot anterior: sudo journalctl -k -b -1 | grep -i oom. El -b -1 indica el penúltimo boot. Si los logs rotativos se borraron, herramientas como last o los logs del panel de tu proveedor pueden confirmar la caída.
¿Prefieres que lo hagamos por ti? En El Enlace resolvemos hosting y desarrollo web profesional.
Recursos útiles
Otros proveedores y guías que vale la pena comparar:
