¿Qué es el OOM Killer de Linux y por qué cierra procesos?
Publicado el 2026-10-26 por frfrand
Cómo reacciona Linux cuando falta memoria, qué hace el OOM Killer y cómo diagnosticar una app que desaparece.
El OOM Killer es un mecanismo del kernel Linux que puede terminar procesos cuando el sistema no puede satisfacer determinadas necesidades de memoria. OOM significa out of memory. No es que Linux cierre programas porque sí: intenta recuperar capacidad ante una situación crítica.
Una forma sencilla de entenderlo
Imaginá un restaurante sin espacio para atender los pedidos que llegan. Si nadie libera una mesa, el encargado debe tomar una decisión incómoda para evitar que todo se bloquee. En un servidor, agotar la memoria puede dejar sin respuesta procesos esenciales.
¿Cómo funciona en la práctica?
Linux administra memoria física, cachés y mecanismos como swap. Cuando la recuperación de memoria no alcanza, puede activar acciones OOM. En entornos con cgroups también existen límites de memoria por grupo o contenedor: un proceso puede sufrir un OOM local aunque el host completo aún tenga memoria disponible.
Lo que no resuelve y sus límites
No todos los procesos cerrados con código 137 fueron necesariamente víctimas del OOM Killer: ese código suele relacionarse con SIGKILL y hay otras causas. Tampoco basta con mirar un pico de RAM. Hay que revisar mensajes del kernel, límites de contenedor, uso de swap y cambios recientes. Aumentar memoria puede dar margen, pero no corrige una fuga de memoria.
Cómo aplicarlo y comprobarlo sin sorpresas
Ante una aplicación que desaparece, buscá registros del kernel y del sistema alrededor de la hora del incidente. Analizá el consumo por proceso y sus límites; revisá el tamaño de workers, concurrencia y consultas que cargan datos enormes. Después probá la corrección bajo una carga reproducible, sin forzar reinicios automáticos interminables.
¿Cómo aparece en ArduMaker?
En un VPS de ArduMaker, los límites de memoria y la carga de servicios como PostgreSQL, Redis o workers condicionan la estabilidad. Supervisar memoria y logs ayuda a distinguir un proceso terminado por OOM de un fallo de despliegue.
El caso de un build que falla con el código 137
Un frontend puede compilar perfectamente en una notebook y fallar al construir dentro de un VPS pequeño. Las herramientas de compilación pueden consumir mucha memoria durante breves períodos. Si el entorno termina el proceso con SIGKILL, buscá primero señales de OOM y comprobá límites reales; no culpes automáticamente al gestor de paquetes ni al framework.
¿Más swap es suficiente?
Swap puede ofrecer margen en algunas cargas, pero es más lenta que RAM y no convierte una máquina pequeña en una grande. Podés reducir concurrencia de builds, separar procesos o construir artefactos en otro entorno antes de desplegar. La solución correcta depende de medir qué consume memoria y cuándo.
Para recordar
El OOM Killer es un mecanismo del kernel Linux que puede terminar procesos cuando el sistema no puede satisfacer determinadas necesidades de memoria. Entender cuándo se aplica, cómo falla y qué datos revisar es más útil que memorizar comandos sueltos.
Para ampliar: Linux kernel documentation: OOM.