Comment le tueur OOM décide-t-il quel processus tuer en premier?

Cette réponse explique les actions entreprises par le noyau lorsqu'une situation de MOO est rencontrée en fonction de la valeur de sysctl vm.overcommit_memory.

Lorsque overcommit_memoryest défini sur 0 ou 1, overcommitest activé et les programmes sont autorisés à allouer plus de mémoire que n'est réellement disponible.

Maintenant, qu'est-ce qui se passe quand nous manquons de mémoire dans cette situation? Comment le tueur OOM décide-t-il quel processus tuer en premier?

Si la mémoire est complètement utilisée par les processus, dans la mesure où cela peut menacer la stabilité du système, alors le destructeur de MOO entre en jeu.

REMARQUE: Le tueur de MOO a la tâche de continuer à supprimer les processus jusqu'à ce que suffisamment de mémoire soit libérée pour permettre le bon fonctionnement du reste du processus que le noyau tente d'exécuter.

Le tueur OOM doit sélectionner le (s) meilleur (s) processus à tuer. Mieux ici, fait référence à ce 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 supprimer le plus petit nombre de processus possible afin de minimiser les dommages causés tout en maximisant la quantité de mémoire libérée.

Pour faciliter ceci, le noyau maintient un oom_scorepour chacun des processus. Vous pouvez voir le oom_scorede chacun des processus dans le /procsystème de fichiers sous le pidrépertoire.

$ cat /proc/10292/oom_score

Plus la valeur d' oom_scoreun processus est élevée, plus grande est sa probabilité d'être tué par le tueur OOM dans une situation de mémoire insuffisante.

Comment est OOM_Scorecalculé?

Dans le jeu de correctifs de David, les anciennes heuristiques de méchanceté () ont presque entièrement disparu. Au lieu de cela, le calcul devient 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, "mémoire disponible" correspond à la somme de la mémoire vive et de l'espace de swap disponible pour le système.

Si au lieu de cela, la situation de MOO est provoquée par l'épuisement de la mémoire autorisée pour un groupe de contrôle / cpuset donné, "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 stratégie de mémoire ont été dépassées. Dans chaque cas, l'utilisation de la mémoire du processus est réputée être la somme de son ensemble de résidents (le nombre de pages RAM utilisées) et de son utilisation d'échange.

Ce calcul produit un nombre pourcentage-fois-dix; un processus utilisant chaque octet de la mémoire disponible aura un score de 1000, alors qu'un processus n'utilisant aucune mémoire obtiendra un score de zéro. Il existe très peu d'ajustements heuristiques à ce score, mais le code soustrait toujours une petite quantité (30) du score des processus possédés par la racine sur la notion qu'ils ont légèrement plus de valeur que les processus détenus par 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’attrait de chaque processus pour le tueur de MOO dans l’espace utilisateur; le mettre à -1000 désactivera entièrement les destructions de MOO, tandis que le réglage à +1000 équivaut à dessiner une grande cible sur le processus associé.

Références

http://www.queryhome.com/15491/whats-happening-kernel-starting-killer-choose-which-process https://serverfault.com/a/571326