Gestión automatizada de OOM Killer para Core-Admin -- Informes OOM killer


#1

1. Introducción

A continuación explicamos cómo funciona el sistema de gestión de informes OOM killer que dispone Core-Admin, cómo se integra con el sistema automatizado de recuperación, y cómo el sistema notifica para un mejor seguimiento.

2. Qué es un incidente OOM-Killer (Linux Kernel)

El sistema Linux, a medida que concede y retira memoria a las distintas aplicaciones para funcionar, si alcanza un límite tras el cual no puede operar y no hay suficiente memoria, entonces activa un proceso OOM-Killer.

Este processo de OOM Killer (literalmente, Asesino debido a falta de memoria, Out of Memory Killer), se encarga de localizar un proceso en cada ronda, atendiendo a distintos parámetros y configuraciones, para desalojarlo de manera forzoza para conseguir recuperar el sistema.

Entre los distintos parámetros de selección tenemos:

A pesar de que hay posibilidad de ajustar distintas puntuaciones (scores), y aplicar distintas técnicas, eso no impide que aparezca un evento OOM-killer ya que la memoria es finita y el número de procesos que se pretenden lanzar en muchos casos es mayor.

3. Etapas y relación con crad-oom-report.pyc

Debido a que OOM-Killer no es un evento que se pueda desactivar, y ya hemos visto que pueden seguir apareciendo a pesar de tener ajustes adecuados, Core-Admin dispone de una herramienta automatizada de último recurso que se ejecuta cada minuto y que intenta recuperar procesos recicables con mayor seguridad siempre que detecte nuevos reportes.

Esta herramienta también permite obtener un escaneo de reportes detectados y también permite obtener un resumen simplificado de los detalles relevantes de cada evento OOM-Killer.

La relación de esta herramienta (crad-oom-report.pyc) y las características de gestión de puntuaciones (oom_score_adj) que proporciona la herramienta de gestión de procesos, es la siguiente:

  • Primera etapa: es deseable utilizar dicha herramienta para ajustar puntuaciones que permitan derivar el OOM-Killer a procesos que sea menos críticos o útiles para nosotros. Consule para ello la página:
    Gestionando eventos system_is_out_of_memory -- Kernel OOM-Killer

  • Segunda etapa: debido a que no es posible evitar del todo el proceso OOM-Killer, crad-oom-report.pyc intentará asistir al kernel parando procesos que pueden permitir recuperar memoria y que tienen un impacto menor en su reinicio.

Es decir, la herramienta de gestión de procesos y servicios para ajustar puntuaciones es para preparar el sistema ante el OOM-Killer y crad-oom-report.pyc es para dichos eventos son lanzados para recuperar antes y mejor.

A continuación explicamos las características detrás de crad-oom-report.pyc.

4. Recuperación automatizada y reporte

crad-oom-report.pyc incluye una opción –tidy que vigila que no se produzcan eventos nuevos de OOM-killer. Si se produce uno, dispara una gestión automatizada para:

  1. Detener procesos con menor impacto en reinicio.

  2. Reportar vía core-admin que hay habido un evento OOM killer nuevo. Cuando esto ocurre, en nuestro visor de core-admin veremos algo como:

  3. En ese caso, ya sabemos que la máquina ha tenido (o está teniendo) problemas de memoria.

  4. A continuación se recomienda pinchar para Mostrar informe de OOM killer de manera que veremos algo como:

    OOM Killer report: ID=1: Sep  4 12:18:52 mailserver01 kernel: [24928263.773721] Mem-Info: (bdfc61ab2c6c64a3a335db7de8e685b0): mailserver01.xxxx.es
    1. Top UID using memory
    | Uid   Username           Total Memory (KB)  Num proc Process names
    | ---   --------           -----------------  -------- -------------
    | 114  |clamav            |2623684           |2 |clamd, freshclam
    | 1004 |kandaduagent      |708780            |2 |init-kandaduage, java
    | 0    |root              |570044            |245      |cron, systemd-logind, agetty, crad-mediator.p, bacula-fd, qe...
    | 110  |mysql             |455040            |1 |mysqld
    | 33   |www-data          |177872            |17 |apache2
    | 1003 |arachnida         |173796            |1 |arachnida
    | 1002 |core-admin-server |27124             |1 |turbulence
    | 1000 |aspl              |6512              |5 |systemd, (sd-pam), sshd, bash, su
    | 107  |postfix           |4796              |4 |tlsmgr, pickup, smtpd
    | 116  |dovecot           |4744              |3 |anvil, stats, auth
    | 117  |dovenull          |3480              |4 |imap-login
    | 1001 |valvulad          |1688              |1 |valvulad
    | 104  |messagebus        |760               |1 |dbus-daemon
    | 119  |vmail             |664               |1 |imap
    | 112  |postfix-gld       |564               |1 |gld
    | uid  |root              |0                 |1 |name
    
    2. Top proc name using memory
    | Process name     Total Memory (KB)
    | ------------     -----------------
    | clamd           |2621216
    | java            |708544
    | mysqld          |455040
    | crad-log-watche |206444
    | apache2         |187880
    | arachnida       |173796
    | config          |66712
    | cron            |46980
    | crad-firewall.p |37476
    | arachnida-check |35708
    ```
    
  5. De esta manera podremos ver qué procesos consumiendo más memoria, o qué usuarios lanzaron más procesos. Desde ahí la ruta de trabajo es distinta, pero es un buen punto de partida para dar un análisis.

  6. Una vez identificado los detalles, pincharemos en Borrar alerta OOM killer para que podamos despejar el panel.

    Esto no borrará la alerta en sí, sino que la hará desaparecer del panel de notificaciones hasta que una nueva alerta aparezca.

5. Cómo saber si el proceso de tidy automatizado está funcionando

Ejecutar el siguiente comando para comprobar que el cron está ejecutando y trabajando:

root@mailserver01:~# grep -i crad-oom-report.pyc /var/log/syslog | grep -i tidy
Sep  5 16:09:01 mailserver01 CRON[25328]: (root) CMD (crad-oom-report.pyc --tidy )
Sep  5 16:10:01 mailserver01 CRON[25662]: (root) CMD (crad-oom-report.pyc --tidy )
Sep  5 16:11:01 mailserver01 CRON[26807]: (root) CMD (crad-oom-report.pyc --tidy )
Sep  5 16:12:01 mailserver01 CRON[27400]: (root) CMD (crad-oom-report.pyc --tidy )
Sep  5 16:13:01 mailserver01 CRON[27741]: (root) CMD (crad-oom-report.pyc --tidy )
Sep  5 16:14:01 mailserver01 CRON[28142]: (root) CMD (crad-oom-report.pyc --tidy )
Sep  5 16:15:01 mailserver01 CRON[28515]: (root) CMD (crad-oom-report.pyc --tidy )
Sep  5 16:16:01 mailserver01 CRON[30253]: (root) CMD (crad-oom-report.pyc --tidy )
Sep  5 16:17:01 mailserver01 CRON[30623]: (root) CMD (crad-oom-report.pyc --tidy )

6. Cómo puedo ver más informes de OOM killers detectados

  1. Siempre puede ejecutar el siguiente comando para obtener un listado de eventos OOM killers, con identificado único (id):

    root@mailserver01:~# crad-oom-report.pyc -l
    Id  Date             File_log Ref Reference
    --  ----             -------- --- ---------
    1  |Sep 4 12:18:52  |/var/log/kern.log |bdfc61ab2c6c64a3a335db7de8e685b0 |Sep  4 12:18:52     mailserver01 kernel: [24928263.773721] Mem-Info:
    2  |Sep 4 12:18:52  |/var/log/kern.log |86eb4e37f0c4c560913482dd62af6551 |Sep  4 12:18:52     mailserver01 kernel: [24928266.868319] Mem-Info:
    3  |Sep 4 12:18:58  |/var/log/kern.log |bfd81fde8025a8abc9a49cdec3d4f979 |Sep  4 12:18:58     mailserver01 kernel: [24928269.055173] Mem-Info:
    4  |Sep 4 12:18:58  |/var/log/kern.log |7ff850592a07ce2195da5503ae813fcb |Sep  4 12:18:58     mailserver01 kernel: [24928273.208415] Mem-Info:
    5  |Sep 4 12:19:01  |/var/log/kern.log |8125edffe570771e67b633366a85ab4e |Sep  4 12:19:01     mailserver01 kernel: [24928276.616801] Mem-Info:
    6  |Sep 4 12:19:06  |/var/log/kern.log |05ed97f92a1e559018d65cb18db3a6d4 |Sep  4 12:19:06     mailserver01 kernel: [24928279.538863] Mem-Info:
    7  |Sep 4 12:19:06  |/var/log/kern.log |0f52ae12b264774aa2bbc94412ffe5bb |Sep  4 12:19:06     mailserver01 kernel: [24928280.678432] Mem-Info:
    8  |Sep 4 12:19:12  |/var/log/kern.log |c983836fe405d4b4ad6de20cc5167baa |Sep  4 12:19:12     mailserver01 kernel: [24928282.857937] Mem-Info:
    9  |Sep 4 12:19:12  |/var/log/kern.log |1671f3d5b0d5a514e6d62ad80dab931c |Sep  4 12:19:12     mailserver01 kernel: [24928286.801090] Mem-Info:
    ...
    
  2. Todos los informes/eventos detectados vienen con la fecha, log de origen y un ID (primera columna). Con ese id, podemos obtener un detalle de informe que deseemos:

    root@mailserver01:~# crad-oom-report.pyc -s 15
    OOM Killer report: ID=15: Aug 30 12:23:48 mailserver01 kernel: [24496556.400627] Mem-Info: (50298aae6bc469cfb0543fe2f33dca5a): mailserver01.xxx.es
    1. Top UID using memory
       | Uid   Username           Total Memory (KB)  Num proc Process names
       | ---   --------           -----------------  -------- -------------
       | 114  |clamav            |2768748           |2 |clamd, freshclam
       | 1004 |kandaduagent      |807120            |2 |init-kandaduage, java
       | 0    |root              |460176            |174 |cron, systemd-logind, agetty, crad-mediator.p, master, bacul...
       | 110  |mysql             |349856            |1 |mysqld
       | 33   |www-data          |181144            |18 |apache2
       | 1003 |arachnida         |163892            |1 |arachnida
       | 1002 |core-admin-server |24340             |1 |turbulence
       | 107  |postfix           |7048              |6 |qmgr, tlsmgr, pickup, anvil, trivial-rewrite, smtpd
       | 116  |dovecot           |4052              |3 |anvil, stats, auth
       | 1001 |valvulad          |1680              |1 |valvulad
       | 104  |messagebus        |760               |1 |dbus-daemon
       | 112  |postfix-gld       |564               |1 |gld
       | uid  |root              |0                 |1 |name
    
    2. Top proc name using memory
       | Process name     Total Memory (KB)
       | ------------     -----------------
       | clamd           |2766392
       ....
    

7. Preguntas habituales

  1. ¿Qué es el evento oom_killer_detected?

    Si en tu panel core-admin ha aparecido este evento, es que se ha producido un evento de OOM-Killer. PIncha es las opciones de mostrar detalles y cuando lo tengas apuntado, puedes darle a borrar de manera que puedas recibir notificaciones frescas.

    Con la información apuntada, ya es valorar lo que dice el informe sobre qué procesos top ocuparon la memoria, o qué top usuarios hicieron lo propio.

    Dependiendo de estos datos, el curso de siguientes pasos variararía.

  2. ¿Hay posibilidad de desactivar el event OOM-Killer?

    No. Es un mecanismo de protección del kernel de Linux para protegerse y seguir en ejecución.

  3. ¿Qué opciones hay cuando se producen estos eventos OOM-Killer (oom_killer_detected)?

    Las opciones disponibles son:

    a) Revisar para limitar el conjunto de procesos que esté lanzando el usuario responsable en mayor parte.

    b) Revisar el código de las aplicaciones involucradas para que no consuman tanto.

    c) Añadir reiniciadores periódicos para los procesos que se sepan gestionan mal la memoria y no la liberan.

    d) Añadir más memoria RAM al servidor.

    e) En algunos casos, añadir SWAP puede ayudar a tener algo de margen, pero no resolverá el problema si no se atienden los puntos anteriores.

8. Resumen

En este artículo hemos explicado el sistema automatizado de recuperación de OOM-Killer de core-admin y qué papel juega crad-oom-report.pyc en el mismo.