Si la memoria se agota exhaustivamente por los procesos, en la medida en que posiblemente pueda amenazar la estabilidad del sistema, entonces el OOM asesino entra en escena.
NOTA: Es tarea del Asesino de OOM continuar eliminando procesos hasta que se libere suficiente memoria para el buen funcionamiento del resto del proceso que Kernel está intentando ejecutar.
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 matar el menor número de procesos que minimiza el daño hecho y al mismo tiempo maximiza la cantidad de memoria liberada.
Para facilitar esto, el núcleo mantiene un oom_scorepara cada uno de los procesos. Puede ver oom_scorecada uno de los procesos en el /procsistema de archivos en el piddirectorio.
$ cat /proc/10292/oom_score
Cuanto mayor sea el valor de oom_scorecualquier proceso, mayor es su probabilidad de ser asesinado por el OOM Killer en una situación sin memoria.
¿Cómo se OOM_Scorecalcula el?
En el conjunto de parches de David, las viejas heurísticas de maldad () han desaparecido casi por completo. En cambio, el cálculo se convierte en una simple pregunta de qué porcentaje de la memoria disponible está siendo utilizada por el proceso. Si el sistema en su conjunto tiene poca memoria, entonces "memoria disponible" es la suma de toda la RAM y el espacio de intercambio disponible para el sistema.
Si, en cambio, la situación de OOM se debe al agotamiento de la memoria permitida para un grupo cpuset / control dado, entonces "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, el uso de memoria del proceso se considera la suma de su conjunto residente (el número de páginas RAM que está usando) y su uso de intercambio.
Como resultado, este cálculo produce un número de porcentaje por diez; un proceso que utiliza todos los bytes de la memoria disponible tendrá un puntaje de 1000, mientras que un proceso que no usa memoria en absoluto obtendrá un puntaje de cero. Hay muy pocos ajustes heurísticos en este puntaje, pero el código aún resta una pequeña cantidad (30) del puntaje de los procesos de propiedad raíz en la noción de que son un poco más valiosos que los procesos de propiedad del usuario.
Otro ajuste que se aplica es agregar el valor almacenado en la variable oom_score_adj de cada proceso, que se puede ajustar a través de / proc. Esta perilla permite el ajuste del atractivo de cada proceso para el asesino de OOM en el espacio del usuario; establecerlo en -1000 deshabilitará las muertes de OOM por completo, mientras que establecerlo en +1000 es el equivalente de pintar un objetivo grande en el proceso asociado.
Referencias
http://www.queryhome.com/15491/whats-happening-kernel-starting-killer-choose-which-process
https://serverfault.com/a/571326