Est-il possible de faire en sorte que l'OOM killer intervienne plus tôt ?

J'ai également été confronté à cette question. Je veux juste que mon système reste réactif, quoi qu'il arrive, et je préfère perdre des processus plutôt que d'attendre quelques minutes. Il semble qu'il n'y ait aucun moyen d'y parvenir en utilisant le kernel oom killer.

Cependant, dans l'espace utilisateur, nous pouvons faire ce que nous voulons. J'ai donc écrit le Early OOM Daemon ( https://github.com/rfjakob/earlyoom ) qui tuera le processus le plus important (par RSS) dès que la RAM disponible sera inférieure à 10 %.

Sans earlyoom, il a été facile de bloquer ma machine (8GB RAM) en démarrant http://www.unrealengine.com/html5/ à plusieurs reprises. Désormais, les onglets de navigateur coupables sont éliminés avant que la situation ne devienne incontrôlable.

La politique par défaut du noyau est d'autoriser les applications à continuer d'allouer de la mémoire virtuelle tant qu'il y a de la mémoire physique libre. La mémoire physique n'est pas réellement utilisée tant que les applications ne touchent pas la mémoire virtuelle qu'elles ont allouée. Une application peut donc allouer beaucoup plus de mémoire que le système n'en a, puis commencer à y toucher plus tard, ce qui fait que le noyau se retrouve à court de mémoire et déclenche le "out of memory" (OOM) killer. Cependant, avant que le processus en question ne soit tué, il a vidé le cache du disque, ce qui ralentit la réponse du système pendant un certain temps, jusqu'à ce que le cache se remplisse à nouveau.

Vous pouvez modifier la politique par défaut pour interdire le surengagement de la mémoire en écrivant une valeur de 2 dans le champ /proc/sys/vm/overcommit_memory . La valeur par défaut de /proc/sys/vm/overcommit_ratio est de 50, de sorte que le noyau ne permet pas aux applications d'allouer plus de 50 % de ram+swap. Si vous n'avez pas d'espace de pagination, le noyau n'autorisera pas les applications à allouer plus de 50 % de votre mémoire vive, laissant les 50 % restants libres pour le cache. Cela peut être un peu excessif, vous pouvez donc augmenter cette valeur à 85 % environ, afin que les applications puissent allouer jusqu'à 85 % de votre mémoire vive, en laissant 15 % pour la mémoire cache.

Pour moi, le réglage de vm.admin_reserve_kbytes=262144 fait exactement cela. Le tueur OOM intervient avant que le système ne devienne complètement insensible.

Les autres réponses proposent de bonnes solutions automatiques, mais je trouve qu'il peut être utile d'activer également la fonction SysRq pour les cas où les choses deviennent incontrôlables. Avec le SysRq vous serez en train de gérer manuellement le noyau, et vous pourrez faire des choses comme un redémarrage sécurisé (avec la touche SysRQ + REISUB ) même si l'espace utilisateur s'est complètement figé.

Pour permettre au noyau d'écouter les requêtes, définissez l'option kernel.sysrq = 1 ou activer uniquement les fonctions que vous êtes susceptible d'utiliser à l'aide d'un masque de bits (documenté par aquí ). A titre d'exemple, on peut citer kernel.sysrq = 244 permettra tous les combos nécessaires au redémarrage en toute sécurité ci-dessus ainsi que l'invocation manuelle de l'OOM killer avec SysRq + F .

La fiabilité n'est pas atteinte par des conditions de faible mémoire et un OOM killer.

_Il n'est pas correct d'organiser une fête dans un placard et d'y placer des objets. "nettoyer mon armoire" sur votre petite liste de lecture._

Est-il possible de faire en sorte que l'OOM killer intervienne plus tôt ?

Ce faisant, vous obtiendrez des résultats inattendus, car vous n'avez aucun contrôle sur ce qui est tué.

J'essaie d'adapter mon système de développement pour qu'il soit le plus fiable possible.

Une fiabilité maximale implique essais votre système et l'améliorer sur la base de ces tests.

Juste une mise au point choses aléatoires ne vous mènera nulle part...

J'ai désactivé le swap, car pour l'utilisation de l'interface graphique, il rend souvent la machine insensible, de sorte qu'elle n'est plus utilisable. Néanmoins, si des applications agressives consomment la mémoire, certains mécanismes semblent se mettre en place pour en tirer le meilleur parti au détriment de la vitesse.

En raison d'une mémoire insuffisante, la désactivation de l'échange n'améliorera pas le comportement , il fait le contraire .

Pour améliorer la fiabilité dans cette situation, ajoutez de la mémoire afin que votre système soit plus réactif et qu'il n'y ait pas de processus aléatoires tués sans l'intention de l'utilisateur. Vous ne devriez pas avoir recours à des conditions de faible mémoire et à un mécanisme comme celui-ci, surtout pas dans un environnement de développement...

Il n'y a pas d'opération d'échange de disque dur, mais le système ne répond plus non plus.

Une mémoire insuffisante entraîne en effet un manque de réactivité, que vous disposiez ou non d'un échange de mémoire.

Je veux donc laisser l'OOM killer agir avant que le système ne fasse des efforts particuliers sur le gain de mémoire.

Des efforts particuliers qui feront plus de mal que de bien, comme je l'ai expliqué plus haut. Au lieu de cela, vous pourriez tuer vous-même les processus dont vous n'avez pas besoin, mais je suppose que vous ne pouvez pas faire cela et que l'OOM tuera les processus dont vous avez besoin.

Est-il possible de configurer l'OOM killer pour qu'il agisse s'il y a moins de 100 Mo de mémoire physique libre, par exemple ?

C'est possible, mais vous obtiendrez un meilleur retour sur investissement en achetant simplement de la mémoire supplémentaire, ce qui ne coûte pas grand-chose de nos jours. Considérez que vous vous tirerez une balle dans le pied à long terme si vous continuez à travailler dans des conditions de faible mémoire. OOM est comme un huissier, il ne vous assiste pas, il assiste l'OS...