Resolviendo el rompecabezas asesino de la falta de memoria

Recientemente presentamos IBM Instana™ Crash Detector, que detecta e informa automáticamente las terminaciones anormales de procesos en todas las máquinas Linux que ejecutan Linux kernel 4.8 y superior. La plataforma IBM Instana emplea las funcionalidades de Extended Berkeley Packet Filter (eBPF) del kernel de Linux para conectarse al propio kernel y comenzar a escuchar las terminaciones de procesos. Cualquier terminación anormal se señala al agente de host, que las compara con los procesos que monitorea para evitar ruidos sobre procesos que no son relevantes y luego envía la información en sentido ascendente al backend de IBM Instana . Se demostró que esta funcionalidad cambia las reglas del juego para nuestros clientes mientras trabajan en la resolución de incidentes.

Con Crash Detector, el software IBM Instana proporciona los datos críticos de muchos de los problemas que afectan al rendimiento de las aplicaciones de nuestros clientes. Ahora estamos mejorando esta funcionalidad mediante la adición de eventos "out-of-memory killer" (OOM killer) a Crash Detector, y es una adición increíblemente valiosa debido a su relevancia para las aplicaciones en contenedores.

La nube puede hacer que parezca que, si tiene suficiente cotización, tiene una potencia informática infinita a su disposición. Sin embargo, esa potencia informática viene en porciones. Hosts (tanto físicos como virtuales), contenedores y funciones: todos vienen con limitaciones en la cantidad de memoria que puede asignar.

En Linux, el asesino de falta de memoria (OOM) es un proceso encargado de evitar que otros procesos agoten colectivamente la memoria del host. Cuando un proceso intenta asignar más memoria de la disponible, el proceso que tiene el puntaje general de maldad más alta (basada, por ejemplo, en la cantidad de memoria que asigna por encima de lo permitido) recibirá una señal OOM. Esto significa fundamentalmente: “Estás fuera de lugar. Salga o haga que algunos de sus procesos secundarios se cierren, o se apagará”.

Tenga en cuenta que el proceso que activa el OOM puede no ser el proceso que recibe la señal OOM. Una aplicación que no aumentó recientemente su uso de memoria puede recibir repentinamente una señal OOM porque demasiadas otras aplicaciones se iniciaron en el mismo host.

La mecánica de una señal OOM suena dura, pero en realidad es un mecanismo muy eficaz para evitar el agotamiento de la memoria en los hosts, especialmente en el caso de aplicaciones que no tienen el tamaño correcto o demasiadas aplicaciones que se ejecutan en paralelo (es decir, los hosts no tienen el tamaño correcto para la carga de trabajo).

Para plataformas contenerizadas como Kubernetes, Cloud Foundry y Nomad, el uso de la memoria, tanto en términos de dimensionamiento adecuado de las aplicaciones como de cuántas aplicaciones ejecutar al mismo tiempo en un host, es aún más importante. Por lo general, no planifica en detalle qué aplicaciones se están ejecutando en ningún nodo. En muchas configuraciones, los contenedores serán asignados de acuerdo con alguna lógica por el orquestador. Hacer cumplir el máximo consumo de memoria es fundamental para los contenedores y grupos de control (cgroups), la base de prácticamente todas las tecnologías de contenedores en Linux. Estos también utilizan el sistema OOM killer para garantizar que los procesos que se ejecutan en el mismo grupo (es decir, un contenedor) no asignen más memoria de la permitida. Cuando los procesos en sus contenedores intentan asignar más memoria de la que se les permite, algunos se terminarán y, a menudo, bajarán sus contenedores con ellos.

A escala, todo es más difícil, incluido el dimensionamiento. Cuantos más contenedores ejecute en sus entornos, más difícil será comprender cuándo, cómo y por qué algunos de ellos se caen. El asesino de OOM puede crear situaciones poco saludables para sus aplicaciones en las que algo siempre falla en algún lugar y luego se resetear, creando una cantidad continua de errores para sus usuarios finales que sesgan sus objetivos de nivel de servicio (SLO) y son realmente difíciles de solucionar.

Descubrir por qué OOM killer eliminó un solo proceso depende mucho de la tecnología que emplee. Algunos paquetes de software lo registrarán en sus propios registros. O puede terminar ejecutando algún comando como el siguiente en sus hosts, en cada uno de ellos:

     #CentOS
 grep -i "out of memory" /var/log/messages
 #Debian / Ubuntu
 grep -i "out of memory" /var/log/kern.log

Parece insípido, pero definitivamente no es el tipo de tarea que desea ejecutar en toda su flota de producción para tratar de entender por qué MySQL volvió a hacer lo mismo a las 3 a.m. Especialmente cuando se trata de una corazonada, ya que nada más parece explicar por qué el proceso de la base de datos ya no está allí.

En otras palabras, OOM killer es un sistema de innegable importancia y eficacia para la fiabilidad que no proporciona suficiente observabilidad. Pero la plataforma IBM Instana está aquí para solucionarlo por usted.

Sobre la base de eBPF que le trajo Crash Detector, el software IBM Instana ahora viene con un detector asesino OOM listo para usar. Cuando su proceso es monitoreado por el software IBM Instana, recibe una señal OOM en tiempo real. No solo eso sucedió, sino también cómo se resolvió la situación (es decir, qué proceso se mató).

Al igual que la mayoría de las características de IBM Instana, todo lo que necesita hacer es instalar el agente de host de IBM Instana y ver cómo el asesino de OOM se ocupa de su sombrío negocio. También muestra cuánta memoria asignó el proceso eliminado en el momento del evento, para que pueda comprender por qué OOM Killer lo marcó como "malo".

Determinar cómo y por qué se terminó un proceso o por qué se eliminó un proceso con un asesino OOM puede llevar horas, si no días, para descubrir sin las herramientas adecuadas. Con IBM Instana Crash Detector, los usuarios ahora tienen inmediatamente la causa principal de cada terminación anormal de procesos y cada proceso exitoso que mata OOM.

¿Necesita entender por qué se perdió un contenedor? No hay problema. Con IBM Instana Crash Detector OOM killer, sabrá que quizás su máquina virtual Java (JVM), al ejecutar un trabajo por lotes muy importante, asignó más recursos de los permitidos. O tal vez necesite determinar la causa por la que tiene tantos errores en las solicitudes del preprocesador de hipertexto (PHP) o por qué su base de datos ha desaparecido. Una vez más, con IBM Instana Crash Detector OOM killer tendrá acceso inmediato a la causa principal de estos problemas.

Para comenzar a ahorrar a usted y a sus equipos de DevOps tiempo en la resolución de eventos asesinos de OOM, simplemente instale el agente IBM Instana en su sistema operativo Linux hoy mismo. Si aún no tiene una instancia de IBM Instana, puede ver cómo funciona IBM Instana Crash Detector with OOM Killer Detection con una prueba gratis.