Empêcher Ubuntu de geler, même si la mémoire système est faible
Parfois, je travaille avec d’énormes quantités de données que je veux garder en mémoire pour le traitement. Parfois, je calcule mal la quantité de mémoire générée par mon programme ou un débogueur multiplie l'utilisation de la mémoire par un facteur supérieur à la quantité de mémoire disponible.
À chaque fois que je lance un processus gourmand en mémoire, voici ce à quoi je m'attendrais d'un système d'exploitation sain: essayez de consommer toute la mémoire libre, puis demandez à un autre processus non essentiel de vous offrir de la mémoire dont vous n'avez pas besoin, puis écrire pour échanger.
Voici ce que Ubuntu fait pour moi: manger toute la mémoire libre, puis demander au système d’exploitation d’échanger tous les services essentiels (session gnome, terminal, clavier), puis de geler et d’attendre que je tire la fiche.
Deux questions:
- Comment un système d'exploitation peut-il supposer que tout peut être si important qu'il est correct d'arrêter d'écouter les commentaires de l'utilisateur?
- Comment puis-je dire à Ubuntu de ne jamais échanger des services essentiels et de toujours réagir aux commentaires de l'utilisateur, même si un processus stupide tente de consommer plus de ressources que le système n'en fournit.
Je n'ai toujours pas de solution au problème, mais je peux proposer deux solutions qui pourraient intéresser d'autres personnes:
C'est un service qui surveille l'utilisation de la mémoire et élimine le processus qui consomme le plus de mémoire lorsqu'un certain seuil est atteint (voir aussi this et this question concernant le tueur de MOO dans le Linux noyau)
Je l'ai testé avec un processus de démonstration qui demande indéfiniment de la mémoire par petits morceaux. Voici ma première impression: lorsque je commence le processus malhonnête, il consomme rapidement toute ma mémoire RAM. Ensuite, la permutation commence, le système ne répond plus. Quelques secondes plus tard, le système est de nouveau en ligne. Le journal de earlyoom indique qu'il a mis fin au processus de restauration de la mémoire après que l'utilisation de la mémoire et de l'échange a atteint 90%.
Il y a toujours le décalage ennuyeux au début de la permutation et après la suppression du processus, certaines parties d'autres processus restent généralement dans la permutation jusqu'à ce qu'elles soient demandées, mais c'est un début.
2) il suffit de désactiver l'échange
Je sais qu’il s’agit d’un sujet controversé , mais pour les ordinateurs de bureau et en particulier les machines de développement où il peut arriver de temps en temps qu’un processus tente de détruire toute votre mémoire, il est logique de: Sans swap, le tueur OOM fonctionne comme prévu. Lorsque vous manquez de mémoire, il trouve le meilleur processus à éliminer et vous en débarrasse. Pas de retard, pas de retard.
Vous pouvez désactiver l'échange pour la session en cours avec Sudo swapoff -a ou rendre la modification permanente .
La solution appropriée au problème serait bien sûr que le système reste réactif lorsque la mémoire principale est épuisée et qu'il commence à changer de mémoire comme s'il n'y avait pas de lendemain, mais cela ne semble pas se produire de si tôt.
J'ai résolu un problème similaire. Je ne sais pas si mon expérience peut vous convenir ...
Récemment, j'ai publié un guide sur la façon d'installer Linux sur des périphériques LVM en boucle à partir d'un périphérique USB (sans avoir à installer grub sur le disque interne, en le laissant comme original). Voici le guide: https://github.com/DareDevil73/linux-on-loopback-usb .
Ensuite, je suis tombé dans le blocage lié au gel dû à une charge de mémoire importante et j’ai observé une utilisation anormale de l’espace de permutation (tous les RAM consommés et une utilisation de l’échange proche de zéro). Il est évident que la partition de swap LVM a été montée et fonctionne correctement, mais je ne sais pas pourquoi le noyau ne l’a pas utilisée comme prévu.
J'ai essayé une solution alternative. J'ai créé un fichier de bouclage d'échange (pas LVM) et le gel est parti. Maintenant, le fichier d'échange est utilisé tel quel et le système d'exploitation ne se fige jamais!
Veuillez regarder https://github.com/DareDevil73/linux-on-loopback-usb#known-issues pour obtenir des informations plus détaillées.
Ubuntu 16.04 est livré avec la version 4.4 du noyau. Dans la version 4.6 du noyau, le tueur de MOO (le tueur de tâche de mémoire insuffisante) subissait une refonte majeure pour traiter les plaintes comme la vôtre. La version 4.6 du noyau est en fin de vie et la version actuelle de la version 4.7.2 du noyau Ubuntu se trouve sur le site Web. Il corrige de nombreux autres problèmes en plus de la mise à niveau du module oom_reaper.
J'ai fait un test la semaine dernière en remplissant RAM + SWAP et l'entrée est restée stable. J'ai également été autorisé à basculer entre les fenêtres actives avec seulement un décalage minisule. Je ne pouvais pas invoquer un nouveau processus tel que 'alt' + 'print screen' mais pouvais invoquer un arrêt méthodique.
Essayez l'une des deux choses suivantes:
1) changez le paramètre swappiness de son paramètre par défaut de 60 à 10, , c’est-à-dire: ajoutez vm.swappiness = 1 en /etc/sysctl.conf (dans le terminal, tapez Sudo gedit /etc/sysctl.conf), puis redémarrez le système. Recherchez ici swappiness pour plus d'informations à ce sujet.
2) Si swappiness ne vous aide pas ... même si vous ne voulez peut-être pas ... augmenter la taille de votre fichier d'échange à 1,5x16G et voir si cela vous aidera.
Tiens moi au courant. À la vôtre, Al