Visión general
Cuando un sistema Linux agota su memoria RAM disponible, entra en acción el mecanismo OOM (Out of Memory) Killer para seleccionar y terminar tareas en función de su puntaje de sacrificio. En este artículo profundizaremos en el comando choom, una utilidad diseñada para auditar y manipular este comportamiento mediante la variable oom_score_adj. Aprenderemos de forma práctica en la terminal a consultar las puntuaciones vigentes, modificar prioridades en tiempo de ejecución y blindar procesos críticos para prevenir su cierre forzado.
1. Fundamentos de choom y preparación del entorno de trabajo
Para experimentar con el ajuste de prioridades OOM y gestionar tareas del sistema, nos aseguramos de contar con las herramientas básicas provistas por los paquetes util-linux y procps:
La herramienta choom interactúa directamente con el kernel de Linux para leer o establecer el valor de compensación oom_score_adj, el cual determina qué procesos serán sacrificados primero ante una emergencia de memoria.
Ejecutando el modificador --help podemos repasar los parámetros fundamentales del comando:
⚙️ [Opciones principales]
-p, --pid : Señala el identificador del proceso (PID) que se desea inspeccionar o reconfigurar.-n, --adjust : Define el nuevo valor de ponderación para el OOM Killer (en una escala de -1000 a 1000).-h, --help : Despliega la ayuda con la sintaxis de uso.-V, --version : Muestra la versión actual del programa.
2. Inspección del puntaje OOM en procesos activos
Con el fin de disponer de una tarea en segundo plano sobre la cual experimentar, lanzamos un comando de espera configurado para 10 minutos mediante sleep 600 &:
A continuación, capturamos el PID correspondiente en la variable TARGET_PID y recurrimos a choom -p para consultar el valor actual de oom_score_adj:
En circunstancias habituales, cualquier proceso recién creado sin alteraciones personalizadas devolverá 0 como puntuación predeterminada.
Para corroborar que la respuesta de choom coincide fielmente con los registros internos del kernel, accedemos directamente al sistema de archivos virtual /proc:
La lectura del archivo valida que el parámetro del kernel se encuentra en 0, ratificando la precisión del comando anterior.
3. Alteración dinámica de la prioridad OOM con choom
Si requerimos que un proceso sea candidato preferente a ser eliminado en caso de saturación de recursos, le asignamos un puntaje positivo elevado —por ejemplo 500— mediante el flag -n y ejecutamos la acción con privilegios administrativos (sudo):
Una ponderación positiva en oom_score_adj incrementa notablemente la probabilidad de que el kernel liquide este proceso ante una crisis de memoria.
Comprobamos de inmediato si el kernel aceptó el nuevo valor ejecutando nuevamente choom -p sobre el identificador objetivo:
El resultado refleja de forma instantánea el cambio desde el valor base 0 hacia el nuevo umbral de 500.
4. Inicialización de procesos protegidos y depuración del sistema
En el caso de servicios críticos que jamás deban interrumpirse, podemos invocarlos estableciendo desde el inicio una compensación de -1000:
Al situar el ajuste en su mínimo absoluto (-1000), el OOM Killer descarta por completo al proceso de su lista de objetivos, manteniéndolo a salvo incluso en escenarios de escasez extrema de memoria.
Almacenamos el PID de esta nueva tarea en TARGET_PID y validamos su configuración con choom -p:
La salida confirma el registro de -1000, lo que demuestra que la protección activa entró en vigor desde el primer instante de ejecución.
Una vez completadas las pruebas, procedemos a liberar los recursos del sistema terminando el proceso que habíamos dejado en ejecución mediante pkill -f 'sleep 600' || true:
Esta práctica garantiza que no queden tareas residuales consumiendo memoria innecesariamente tras nuestras sesiones de laboratorio.
Dominar el uso de choom constituye una habilidad indispensable para cualquier administrador de sistemas que busque optimizar la resiliencia en Linux. Ajustar de forma estratégica la susceptibilidad de cada servicio frente al OOM Killer asegura la continuidad de las cargas de trabajo más críticas en entornos de producción.