Est-il possible de faire intervenir le tueur OOM plus tôt?

34

J'essaie d'adapter mon système de développement à une fiabilité maximale. J'ai désactivé le swap, car pour l’utilisation de l’interface graphique, la machine ne répond plus, ce qui la rend inutilisable. Néanmoins, si des applications agressives consomment de la mémoire, certains mécanismes semblent permettre de tirer le meilleur parti de la vitesse. Il n'y a pas d'opération d'échange de disque dur, mais le système ne répond plus de la même manière. Je souhaite donc que le tueur OOM vienne à l'action avant que le système ne déploie des efforts particuliers pour améliorer la mémoire. Est-il possible de configurer le tueur de MOO pour qu'il agisse s'il y a moins de 100 Mo de mémoire physique libre, par exemple?

linux-kernel memory-management

— dronus
source

2

Je pense que le vrai problème, c'est qu'il n'y a pas assez de bélier pour commencer. Vous n'utiliserez pas d'échange sauf s'il n'y a pas de bélier. En désactivant l’échange ... vous manquez de bélier et n’avez nulle part où le rechercher. Ce qui fait que des choses laides se produisent. Votre système semble mal configuré et aucun ajustement ne réglera le problème.

— Compagnon Geek

8

Je ne suis pas d'accord Le développement et la «consommation d'énergie» impliquent souvent un usage expérimental. Par exemple, lors de l'utilisation d'un outil de traitement d'image en ligne de commande, il n'y a pas de précision sur la quantité de mémoire utilisée par l'opération en fonction de la taille de l'image. Alors je lui donne juste une course. Et je ne m'attends pas à ce que cela rende toute ma machine inutile. Pour une expérience unique, je pourrais utiliser ulimit pour le maintenir sécurisé, mais pour un système complet avec parfois beaucoup d’opérations, le confinement d’un processus n’est pas très utile, mais une «assurance vie» pour l’ensemble de la machine.

— dronus

1

Le fait que votre système s'arrête lorsque vous utilisez swap est suspect. Votre ordinateur utilise l’échange car il manque de mémoire. L'échange ralentit car l'accès au disque est lent. L'accès au disque est lent à cause de ???. Ses problèmes tout en bas. Ce n'est pas juste que vous êtes bas sur le bélier. C'est que vous ne pouvez pas utiliser l'un des moyens d'atténuer cela en raison de quelque chose d'autre.

— Journeyman Geek

7

@JourneymanGeek, vous êtes dans le champ de gauche. Les disques sont lents par rapport au bélier, au point, donc un échange important arrête toujours le système. Bien sûr, il manque de mémoire car il a essayé d’exécuter un programme qui utilise beaucoup de mémoire. La question est de savoir quoi faire quand il manque de mémoire? Tuez le porc ou ralentissez-vous car vous n'avez plus de mémoire pour le cache du disque.

— Psusi

2

@TomWijsman, les entrées-sorties de disque étant de plusieurs ordres de grandeur plus lents que les entrées-sorties de mémoire, l'échange de disque a toujours entraîné un ralentissement considérable. Parfois (surtout à l’époque où le bélier était cher et que la plupart des gens n’en avaient pas beaucoup), il était préférable de ne pas pouvoir faire ce que vous essayiez du tout. De nos jours, le disque est TELLEMENT beaucoup plus lent que le bélier, et le bélier est assez bon marché pour que la plupart des gens en aient beaucoup. Ainsi, dans les rares cas où ils utilisent accidentellement quelque chose qui utilise plus de bélier que ce qu'ils ont, il vaut souvent mieux abandonner que de prendre 1000 fois aussi longtemps pour le faire.

— Psusi

36

J'ai également lutté avec ce problème. Je veux juste que mon système reste réactif, quoi qu'il en soit, 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 démon Early OOM ( https://github.com/rfjakob/earlyoom ) qui supprimera le plus gros processus (par RSS) une fois que la RAM disponible sera inférieure à 10%.

Sans le début de la session, il a été facile de verrouiller ma machine (8 Go de RAM) en démarrant http://www.unrealengine.com/html5/ à quelques reprises. Maintenant, les onglets du navigateur coupables sont tués avant que les choses ne deviennent incontrôlables.

— Jakob
source

3

Merci de gratter cette démangeaison! Aimer earlyoom jusqu'à présent.

— Thomas Ferris Nicolaisen

1

J'ai juste compris qu'Android faisait la même chose depuis longtemps. Je ne suis pas sûr s'il utilise un code personnalisé comme le vôtre pour cela.

— dronus

1

Je teste earlyoommaintenant, il fait bien dans un premier test de déclenchement. Je me demande simplement pourquoi cela ne peut pas être mis en œuvre par la configuration du noyau ou les outils système.

— dronus

12

La politique par défaut du noyau est de permettre aux applications de continuer à allouer de la mémoire virtuelle tant qu'il reste de la mémoire physique. La mémoire physique n'est réellement utilisée que lorsque les applications touchent la mémoire virtuelle allouée. Une application peut donc allouer beaucoup plus de mémoire que le système, puis commencer à la toucher plus tard, ce qui entraîne une insuffisance de mémoire du noyau et le déclenchement de la sortie. de la mémoire (MOO) tueur. Cependant, avant que le processus de monopolisation ne soit tué, le cache de disque a été vidé, ce qui ralentit le temps de réponse du système jusqu'à ce que le cache se remplisse.

Vous pouvez modifier la stratégie par défaut pour interdire tout dépassement de mémoire en écrivant une valeur de 2 à /proc/sys/vm/overcommit_memory. La valeur par défaut /proc/sys/vm/overcommit_ratioest 50. Par conséquent, le noyau n'autorisera pas les applications à allouer plus de 50% de ram + swap. Si vous n'avez pas d'échange, le noyau n'autorisera pas les applications à allouer plus de 50% de votre mémoire RAM, laissant les 50% restants libres pour le cache. Cela peut être un peu excessif, vous pouvez donc augmenter cette valeur pour qu’elle atteigne environ 85%, afin que les applications puissent allouer jusqu’à 85% de votre mémoire vive, laissant 15% pour le cache.

— psusi
source

1

Changer ces valeurs à partir de leurs valeurs par défaut sans connaissances théoriques ne va pas arriver à un système plus fiable, vous ne pouvez justifier ce changement qu'avec des statistiques appropriées. Ce n'est pas parce que vous pouvez changer que vous devriez. Si vous restez constamment dans des conditions de mémoire insuffisante, cela signifie que vous utilisez plus de mémoire que vous ne devriez en acheter plus, cela ne signifie pas que vous devriez modifier vos paramètres et tuer des applications aléatoires. Interrompre votre travail quotidien ou introduire la corruption, ce n'est vraiment pas la voie à suivre ...

— Tamara Wijsman

3

@TomWijsman, la question montre clairement qu'il n'est pas constamment dans des conditions de mémoire insuffisante; il exécute parfois une commande nécessitant une quantité de mémoire inattendue. Acheter plus de mémoire n'est pas la seule solution lorsque vous en manquez. Parmi les autres solutions possibles, citons la recherche de meilleurs moyens d’utiliser la mémoire que vous avez ou tout simplement de ne pas utiliser tout ce qui vous manque. La question précise que ce dernier est plus acceptable que de sortir et d'acheter plus de bélier.

— Psusi

Quelle ligne dans la question le dit clairement? Je vois le contraire donné dans I disabled swap, because for GUI usage it mostly renders the machine unresponsive in such a way not useable anymore.. Il a mentionné l'interface graphique, alors que vous supposez qu'il exécute une commande. L'achat de plus de mémoire est la première solution, l'utilisation de moins de mémoire vous-même est la deuxième solution. Rendre votre système instable en bidouillant les valeurs par défaut stables est la dernière solution. Il n'est pas nécessaire de répondre à la question à la lettre, alors je ne vois pas en quoi votre problème est que vous devez nous déranger tous les deux dans les commentaires. Rant n'aide pas ...

— Tamara Wijsman

4

Hé, cette réponse semblait plutôt cool. Malheureusement, le «commit» fait référence à la demande de mémoire virtuelle, ce qui est assez mauvais estimé par les programmeurs d'applications. Par exemple , avec mon (pas de swap) en cours d'exécution bureau, il y a environ 400 2000MB mémoire utilisée, mais 1600 Mo « commit'ted comme /proc/meminfo» de Committed_ASles États. Avec certaines applications en cours d'exécution, cette valeur dépasse facilement la mémoire physique, il est donc difficile de définir une limite réalisable de cette manière.

— dronus

3

Enregistrez votre travail avant d'essayer cela! : PI a eu des échecs immédiats de tout (bash, gestionnaire de fenêtres, etc.).

— Jozxyqk

8

Pour moi, définir vm.admin_reserve_kbytes = 262144 fait exactement cela. Le tueur OOM intervient avant que le système ne soit complètement insensible.

— Michael Vigovsky
source

1

J'aime l'idée, mais cela signifie-t-il que vous avez 256 Mo de mémoire physique jamais utilisée?

— Jérôme Pouiller

1

256 Mo seront utilisés pour les caches. Les caches sont vraiment importants, il ne s'agit pas simplement de courir plus vite, le système ne fonctionnerait pas du tout s'il n'y avait pas assez de mémoire pour les caches. Le code de chaque programme en cours d'exécution peut être déchargé de la mémoire car il est mappé et peut être lu à partir du disque. Sans cache, chaque commutateur de tâches nécessitera une lecture de disque et le système ne répondra plus du tout.

— Michael Vigovsky

4

Les autres réponses ont de bonnes solutions automatiques, mais j'estime qu'il peut être utile d'activer également la SysRqclé lorsque la situation devient incontrôlable. Avec leSysRq clé, vous enverriez manuellement le noyau par messagerie, et vous pourrez effectuer des opérations telles qu’un redémarrage sécurisé (avec SysRQ + REISUB) même si l’espace utilisateur est complètement gelé.

Pour permettre au noyau d'écouter les requêtes, de définir kernel.sysrq = 1ou d'activer uniquement les fonctions que vous êtes susceptible d'utiliser avec un masque de bits (documenté ici ). Par exemple kernel.sysrq = 244, tous les combos nécessaires au redémarrage sécurisé ci-dessus seront activés, ainsi que l’invocation manuelle du tueur de MOO avec SysRq + F.

— timuzhti
source

-2

La fiabilité n'est pas atteinte par des conditions de mémoire insuffisante et un tueur de MOO.

Il est faux d'organiser une fête dans un placard et de placer "nettoyer mon placard" sur votre petite liste de lecture.

Est-il possible de faire intervenir le tueur OOM plus tôt?

Cela aura 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 à une fiabilité maximale.

La fiabilité maximale implique de tester votre système et d'améliorer votre système en fonction de ces tests.

Le simple fait de modifier des choses aléatoires ne vous mènera nulle part ...

J'ai désactivé le swap, car pour l’utilisation de l’interface graphique, la machine ne répond plus, ce qui la rend inutilisable. Néanmoins, si des applications agressives consomment de la mémoire, certains mécanismes semblent permettre de tirer le meilleur parti de la vitesse.

En raison des conditions de mémoire insuffisante, la désactivation de l'échange n'améliorera pas le comportement , mais le contraire .

Pour augmenter la fiabilité dans cette situation, ajoutez plus de mémoire de sorte que votre système soit plus réactif et qu'aucun processus aléatoire ne soit tué sans la volonté de l'utilisateur. Vous ne devriez pas avoir recours à des conditions de mémoire insuffisante et à un mécanisme comme celui-ci, en particulier 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 de la même manière.

Les conditions de mémoire insuffisante entraînent en effet une absence de réponse, que vous ayez un échange ou non.

Je souhaite donc que le tueur OOM vienne à l'action avant que le système ne déploie des efforts particuliers pour améliorer la 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 pouvez tuer des processus dont vous n'avez pas besoin vous-même, mais je suppose que vous ne pouvez pas le faire, alors le MOO supprimera les processus dont vous avez besoin.

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

Peut-être, mais vous obtenez un retour sur investissement plus élevé si vous achetez simplement de la mémoire supplémentaire qui ne coûte pas vraiment cher ces jours-ci. Considérez que vous allez vous frapper le pied à long terme si vous continuez à travailler dans des conditions de mémoire insuffisante. OOM est comme un huissier de justice, il ne vous assiste pas, il assiste l'OS ...

— Tamara Wijsman
source

7

Bien sûr, la désactivation du swap améliore le comportement car au lieu de forcer le disque, le MOO entre en action et tue la mémoire. Le manque de mémoire vive n'est pas le problème (et en ajouter davantage signifie simplement que vous devez essayer plus fort pour vous épuiser). Le problème est de savoir quoi faire quand vous êtes à court. Vous voulez que le MOO tue le porc et soulage ainsi les conditions de mémoire insuffisante.

— Psusi

7

Car tuer une application qui tente d'utiliser plus de mémoire que vous en avez est préférable à mettre tout le système à genoux. Dans un monde parfait, vous auriez une mémoire illimitée et ne vous épuiseriez jamais, mais en réalité, il vous arrivera parfois de vous épuiser par accident. Vous préféreriez plutôt se faire dire «pas assez de mémoire» plutôt que de faire arrêter le système.

— Psusi

5

L'achat de mémoire supplémentaire peut résoudre certains problèmes, selon le montant acheté. Mais cela ne change pas le fait qu'il peut y avoir des utilisations imprévues par ordres de grandeur. Je souhaite donc que l'application échoue, mais PAS le système dans ces conditions. Quelques exemples: Traitez un dossier plein d’images compressées, la plupart d’entre elles de taille «normale», mais certaines d’entre elles sont vraiment volumineuses. Une petite erreur pourrait faire une boucle morte avec mémoire emballée mangeant 1 Go / s. Ouvrir accidentellement un fichier vidéo dans un éditeur de texte. Cela se termine habituellement par des symptômes tels qu'une souris saccadée et une interface utilisateur presque morte jusqu'à ce que le MOO entre en action.

— dronus

6

@TomWijsman il existe également des boucles presque mortes car il existe des algorithmes qui se comportent de manière linéaire dans le cas moyen, mais exponentiels dans le pire des cas, en fonction des données d'entrée. Et je ne peux pas envoyer de signal de mise à mort si la souris est saccadée et que les clics ainsi que la saisie au clavier indiquent une latence d'une minute. Je passe généralement à un terminal en mode texte à ce moment-là et attends quelques minutes pour que la connexion se déroule juste pour émettre un killmessage tapé à l'aveugle.

— dronus

7

Je n'ai aucun problème à tuer des applications qui seraient mortes non plus. Considérons un système avec 2 Go d'échange physique + 2 Go. Une application qui utilise rapidement la mémoire physique peut aussi facilement utiliser l’échange. Il mourrait plus tard, après avoir rendu le système inactif pendant quelques minutes à quelques heures. Alors pourquoi ne pas le tuer rapidement avant que l'interface graphique ne devienne floconneuse? De nombreux processus font tout leur travail avec 10 Mo, certains prennent 1 Go, et certains rares auraient besoin de 10 Go, c'est la vie.

— dronus