Cette réponse explique les actions entreprises par le noyau lorsqu'une situation OOM est rencontrée en fonction de la valeur de sysctl vm.overcommit_memory .
Lorsque overcommit_memory est défini sur 0 ou 1, overcommit est activé et les programmes sont autorisés à allouer plus de mémoire que ce qui est réellement disponible.
Maintenant, que se passe-t-il lorsque nous manquons de mémoire dans cette situation ? Comment le tueur OOM décider quel processus tuer en premier ?
Réponse acceptée :
Si la mémoire est utilisée de manière exhaustive par les processus, dans la mesure où cela peut éventuellement menacer la stabilité du système, alors le tueur de MOO entre en scène.
REMARQUE : C'est la tâche du OOM Killer de continuer à tuer les processus jusqu'à ce que suffisamment de mémoire soit libérée pour le bon fonctionnement du reste du processus que le noyau tente d'exécuter.
L'OOM Killer doit sélectionner le meilleur processus(s) pour tuer. Meilleur fait ici référence au processus qui libérera le maximum de mémoire lors de la mise à mort et qui est également le moins important pour le système.
L'objectif principal est de tuer le plus petit nombre de processus qui minimise les dommages causés tout en maximisant la quantité de mémoire libérée.
Pour faciliter cela, le noyau maintient un oom_score pour chacun des processus. Vous pouvez voir le oom_score de chacun des processus dans le /proc système de fichiers sous le pid répertoire.
$ cat /proc/10292/oom_score
Plus la valeur de oom_score est élevée de tout processus, plus sa probabilité d'être tué par le OOM Killer est élevée dans une situation de mémoire insuffisante.
Comment est le OOM_Score calculé ?
Dans l'ensemble de correctifs de David, l'ancienne heuristique badness() a presque entièrement
disparu. Au lieu de cela, le calcul se transforme en une simple question de savoir quel
pourcentage de la mémoire disponible est utilisé par le processus. Si
le système dans son ensemble manque de mémoire, alors la "mémoire disponible" est
la somme de toute la RAM et de l'espace d'échange disponible pour le système.Si au lieu de cela, la situation OOM est causée par l'épuisement de la mémoire allouée
à un cpuset/groupe de contrôle donné, alors la « mémoire disponible » est la quantité totale
allouée à ce groupe de contrôle. Un calcul similaire est effectué
si les limites imposées par une politique de mémoire ont été dépassées. Dans chaque cas,
l'utilisation de la mémoire du processus est considérée comme étant la somme de son
ensemble résident (le nombre de pages de RAM qu'il utilise) et de son utilisation de swap.Ce calcul produit en conséquence un nombre multiplié par dix ; un
processus qui utilise chaque octet de la mémoire disponible obtiendra
un score de 1000, tandis qu'un processus n'utilisant pas de mémoire du tout obtiendra
un score de zéro. Il y a très peu d'ajustements heuristiques à ce score,
mais le code soustrait toujours une petite quantité (30) du score des
processus appartenant à la racine sur la notion qu'ils sont légèrement plus
précieux que les processus appartenant à l'utilisateur.Un autre ajustement appliqué consiste à ajouter la valeur stockée dans la variable oom_score_adj de chaque
processus, qui peut être ajustée via /proc.
Ce bouton permet d'ajuster l'attractivité de chaque processus pour
le MOO tueur dans l'espace utilisateur ; le régler sur -1000 désactivera entièrement les éliminations de OOM
, tandis que le régler sur +1000 équivaut à peindre une
grande cible sur le processus associé.
Références
Connexe :Inconvénient lors de l'utilisation d'un chroot dans le calcul haute performance ?http://www.queryhome.com/15491/whats-happening-kernel-starting-killer-choose-which-process https://serverfault.com/a/571326