Gestionando eventos system_is_out_of_memory -- Kernel OOM-Killer


#1

1. Introducción

El siguiente artículo explica cómo gestionar los eventos system_is_out_of_memory disparados por la activación del OOM-Killer del kernel de linux en situaciones de límites de memoria alcanzados y cómo poder configurar las puntuaciones (scores) para que el OOM-Killer realice un trabajo mejor alineado con nuestros intereses.

2. Requisitos

Este artículo sólo te será útil en caso de que tengas una máquina y seas administrador sobre ella.

3. El OOM-Killer del kernel de Linux

En condiciones de funcionamiento normal las propias aplicaciones Linux incluyen mecanismos de control para evitar solicitar más memoria de la que esté disponible o de la configurada por el administrador.

Sin embargo, existen muchas aplicaciones que carecen de estos controles y siguen solicitando memoria aun cuando no hay disponible.

Para protegerse, el kernel de linux incluye un componente llamado OOM-Killer (Out of Memory Killer), que se activa para hacer una selección de procesos que mejor puntuación tengan (oom_score_adj) para ser detenidos.

Estas puntuaciones las va variando el propio kernel en función de distintos factores, como la interactividad, la entrada/salida, cantidad de swap generada por el proceso, cantidad de cpu consumida, entre otros. Estas puntuaciones también pueden ser tocadas por el administrador.

4. Qué no hay que hacer con respecto al OOM-Killer

A pesar de la impresión inicial, este componente es impresdindible.

No debemos luchar contra él. Realmente la existencia y activación del OOM-Killer es una señal de que el sistema está consumiendo más de lo que debe y en caso de no activarse, correría el riesgo de echar todo el servidor abajo.

Existen distintas opciones para gestionar el memory overcommit, swapiness y opciones similares. Sin embargo, todas ellas no dan buen resultado en la práctica.

Lo mejor y lo más recomendado es aceptar que el OOM-Killer se puede activar y en tal caso, nuestro sistema tiene que aportar las mejores puntuaciones de los procesos que nos interesa que sean detenidos y cuáles no nos interesa en absoluto.

5. Gestión de puntuaciones del OOM-Killer con Core-Admin (oom_score_adj): gestor de políticas de oom-killer

A continuación te explicamos cómo gestionar políticas para el oom-killer donde puedes definir patrones de selección de procesos y puntuaciones que hay que configurar del manera que el OOM-Killer no dispare a cualquier cosa:

  1. Necesitas un Core-Admin totalmente actualizado. Actualiza desde el panel (Sistema -> Actualizaciones) o desde línea de comandos como root:

    >> crad-update.pyc -u
    >> crad-update.pyc -g -f -d
    
  2. Una vez actualizado dirígete a la gestión de servicios y procesos de tu máquina con:

  3. Dentro, accede a la sección de políticas:

  4. Ahí verás listadas las políticas por defecto que te proporciona Core-Admin y que pretenden proteger servicios críticos conocidos y dar puntuaciones bajas a servicios y procesos que se pueden reciclar sin causar grandes problemas.

  5. El sistema de políticas es simple: si algún proceso tiene un comando de arranque similar al patrón definido, se le configurará la puntuación indicada.

  6. Para el OOM-Killer, una puntuación de -1000 es la de menor peso, menor puntuación para ser candidato a ser detenido. Al contrario, una puntuación de 1000 es la de mayor peso, es una indicación de proceso que ha de ser detenido en caso de falta de memoria.

  7. Todas las políticas que definas en esta sección serán reforzadas y supervisadas constantemente por core-admin (por el proceso crad-log-watcher.pyc) para asegurar que si cualquier servicio es reiniciado, se le asignará su puntuación como corresponda a las políticas.

6. Cómo supervisar la aplicación de las políticas para el OOM-Killer

Ejecuta el siguiente comando. Te dará una indicación de la activación del OOM-Killer y de la aplicación de las políticas por parte de Core-Admin:

>> grep -i oom /var/log/syslog
Nov 30 11:27:56 node02-xxx crad-log-watcher[30184]: Applying oom killer policy [php-fpm: pool] -1000 -> 1000 to pid [7701] because [php-fpm: pool] in [php-fpm: pool tpv.xxx.com]
Nov 30 11:28:31 node02-xxx crad-log-watcher[30184]: Applying oom killer policy [php-fpm: pool] -1000 -> 1000 to pid [7854] because [php-fpm: pool] in [php-fpm: pool xxx.com]
Nov 30 11:28:38 node02-xxx crad-log-watcher[30184]: Applying oom killer policy [php-fpm: pool] -1000 -> 1000 to pid [7875] because [php-fpm: pool] in [php-fpm: pool xxx.com]
Nov 30 11:28:38 node02-xxx crad-log-watcher[30184]: Applying oom killer policy [php-fpm: pool] -1000 -> 1000 to pid [7876] because [php-fpm: pool] in [php-fpm: pool xxx.com]