OOM el asesino de hijos

Es solo una conjetura, dado que en un servidor todos los procesos son descendientes del proceso de inicio de Linux, el principal en este contexto es un proceso de Linux donde los secundarios son las diversas aplicaciones. En este caso, el proceso de Linux se intenta recuperar al matar a uno de sus hijos.

Si los procesos hijos agotan la memoria de forma exhaustiva, en la medida en que pueda amenazar la estabilidad del sistema, el asesino OOM entra en escena.

Y es cuando aparece un mensaje con este en los log del sistema

Out of memory: Kill process 7429 (java) score 259 or sacrifice child

no se trata de algún ritual oscuro para mantener las cosas en marcha.

El mensaje sugiere el agotamiento de memoria por lo que java
es el hijo que tiene una taza muy alta de consumo por lo es un candidato al
sacrificio.

¿Cómo lo hace?

El OOM Killer tiene que seleccionar los mejores procesos para matar. Lo mejor aquí se refiere a ese proceso que liberará la memoria máxima al matar y también es el menos importante para el sistema.

El objetivo principal es eliminar el menor número de procesos que minimice el daño causado y al mismo tiempo maximice la cantidad de memoria liberada.

Cuanto mayor sea el valor de oom_score cualquier proceso, mayor será su probabilidad de ser asesinado por el OOM Killer en una situación de falta de memoria.

¿Cómo decide el asesino OOM qué hijo matar primero?

Cuando el sistema se queda sin memoria, el kernel de Linux destruye los procesos para liberar memoria. Una heurística determina qué proceso es el mejor candidato para liberar memoria sin dañar el sistema (por lo general, los procesos de propiedad raíz no son los mejores candidatos).

el cálculo se convierte en una pregunta simple sobre qué porcentaje de la memoria disponible está utilizando el proceso. Si el sistema en su conjunto carece de memoria, entonces «memoria disponible» es la suma de toda la RAM y el espacio de intercambio disponible para el sistema.

Si, por el contrario, la situación de OOM se produce al agotar la memoria permitida para un grupo de control / grupo de servidores dado, entonces la «memoria disponible»
es la cantidad total asignada a ese grupo de control. Se realiza un cálculo similar si se han excedido los límites impuestos por una política de
memoria. En cada caso, se considera que el uso de memoria del proceso es
la suma de su conjunto residente (el número de páginas RAM que usa) y su uso de intercambio.

Este cálculo produce como resultado un número de porcentajes de diez veces; un proceso que utiliza cada byte de la memoria disponible tendrá una puntuación de 1000, mientras que un proceso que no utiliza memoria obtendrá una puntuación de cero. Hay muy pocos ajustes heurísticos en esta puntuación, pero el código aún resta una pequeña cantidad (30) de la puntuación de los procesos de raíz, en la noción de que son ligeramente más valiosos que los procesos propiedad de los usuarios.

Otro ajuste que se aplica es agregar el valor almacenado en la variable oom_score_adj de cada proceso, que se puede ajustar mediante /proc. Esta perilla permite el ajuste del atractivo de cada proceso para el asesino OOM en el espacio del usuario; establecerlo en -1000 deshabilitará la eliminación de OOM por completo, mientras que establecerlo en +1000 equivale a pintar un objetivo grande en el proceso asociado.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *