Esta respuesta explica las acciones que toma el kernel cuando se encuentra una situación OOM basada en el valor de sysctl vm.overcommit_memory .
Cuando overcommit_memory se establece en 0 o 1, overcommit está habilitado y los programas pueden asignar más memoria de la que realmente está disponible.
Ahora, ¿qué sucede cuando nos quedamos sin memoria en esta situación? ¿Cómo funciona el asesino OOM decidir qué proceso eliminar primero?
Respuesta aceptada:
Si la memoria se utiliza de forma exhaustiva por los procesos, en la medida en que posiblemente pueda amenazar la estabilidad del sistema, entonces el asesino OOM entra en escena.
El OOM Killer tiene que seleccionar el mejor proceso(s) para matar. Mejor aquí se refiere a ese proceso que liberará el máximo de memoria al matar y también es el menos importante para el sistema.
El objetivo principal es eliminar la menor cantidad de procesos que minimice el daño causado y, al mismo tiempo, maximice la cantidad de memoria liberada.
Para facilitar esto, el kernel mantiene un oom_score para cada uno de los procesos. Puedes ver el oom_score de cada uno de los procesos en el /proc sistema de archivos bajo el pid directorio.
$ cat /proc/10292/oom_score
Cuanto mayor sea el valor de oom_score de cualquier proceso, mayor es la probabilidad de ser eliminado por el OOM Killer en una situación de falta de memoria.
¿Cómo es el OOM_Score? calculado?
En el conjunto de parches de David, la antigua heurística badness() ha desaparecido casi por completo. En su lugar, el cálculo se convierte en una simple cuestión de qué porcentaje de la memoria disponible está utilizando el proceso. Si
al sistema en su conjunto le falta memoria, entonces la "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 debe a que se agotó la memoria permitida
a un conjunto de cpu/grupo de control 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,
el uso de memoria del proceso se considera que es la suma de su conjunto residente
(la cantidad de páginas de RAM que está usando) y su uso de intercambio.
Este cálculo produce como resultado un número de porcentaje por diez; un proceso
que utilice cada byte de la memoria disponible tendrá
una puntuación de 1000, mientras que un proceso que no utilice ninguna memoria obtendrá
una puntuación de cero. Hay muy pocos ajustes heurísticos a esta puntuación,
pero el código aún resta una pequeña cantidad (30) de la puntuación de
procesos propiedad de la raíz en la noción de que son un poco más
valiosos que los procesos 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 OOM asesino en el espacio del usuario; establecerlo en -1000 deshabilitará OOM
mata por completo, mientras que establecerlo en +1000 es el equivalente a pintar un
objetivo grande en el proceso asociado.
Referencias
Relacionado:¿Inconveniente al usar un chroot en computación de alto rendimiento?http://www.queryhome.com/15491/whats-happening-kernel-starting-killer-choose-which-process https://serverfault.com/a/571326