Pendant des années, le tueur OOM de mon système d'exploitation ne fonctionne pas correctement et conduit à un système gelé.
Lorsque l'utilisation de la mémoire est très élevée, l'ensemble du système a tendance à "geler" (en fait :devenir extrêmement lent) pendant heures ou même jours , au lieu de tuer des processus pour libérer de la mémoire.
Le maximum que j'ai enregistré est de 7 jours avant de me résigner à opérer un reset.
Lorsque OOM est sur le point d'être atteint, le iwait est très très élevé (~ 70%), avant de devenir non mesurable.
L'outil :iotop a montré que tous les programmes lisent à un débit très élevé (par dizaines de Mo/sec) à partir de mon disque dur.
Que lisent ces programmes ?
– La hiérarchie des répertoires ?
– Le code exécutable lui-même ?
Je ne sais pas exactement maintenant.
[édité] Au moment où j'ai écrit ce message (en 2017), j'utilisais une mise à jour ArchLinux (4.9.27-1-lts), mais j'avais déjà rencontré le problème pendant des années auparavant.
J'ai rencontré le même problème avec diverses distributions Linux et différentes configurations matérielles.
Actuellement (2019), j'utilise une mise à jour Debian 9.6 (4.9.0)
J'ai 16 Go de ram physique, un SSD sur lequel mon OS est installé, et pas n'importe quel swap partitionner.
En raison de la quantité de RAM dont je dispose, je ne souhaite pas activer une partition d'échange, car cela ne ferait que retarder l'apparition du problème.
De plus, l'échange trop fréquent de SSD pourrait potentiellement réduire la durée de vie du disque.
D'ailleurs, j'ai déjà essayé avec et sans partition de swap, cela s'est avéré ne faire que retarder l'apparition du problème, mais n'étant pas la solution.
Pour moi, le problème est causé par le fait que Linux supprime les données essentielles des caches , ce qui conduit à un système gelé car il doit tout lire, à chaque fois depuis le disque dur.
Je me demande même si Linux ne laisserait pas tomber les pages de codes exécutables des programmes en cours d'exécution, ce qui expliquerait pourquoi les programmes qui ne lisent normalement pas beaucoup de données se comportent de cette façon dans cette situation.
J'ai essayé plusieurs choses dans l'espoir de résoudre ce problème.
L'une consistait à définir /proc/sys/vm/min_free_kbytes à 1000000 (1 Go).
Parce que ce 1 Go devait rester libre, je pensais que cette mémoire serait réservée par Linux pour mettre en cache des données importantes.
Mais ça n'a pas marché.
De plus, je pense utile d'ajouter que même si cela peut sembler génial en théorie, limiter la taille de la mémoire virtuelle à la taille de la mémoire physique, en définissant /proc/sys/vm/overcommit_memory à 2 n'est pas décemment techniquement possible dans ma situation, car le type d'applications que j'utilise nécessite plus de mémoire virtuelle qu'elles n'en utilisent effectivement pour certaines raisons.
Selon le fichier /proc/meminfo , le Commited_AS est souvent supérieure au double de la RAM physique de mon système (16 Go, Commited_AS est souvent> 32 Go).
J'ai rencontré ce problème avec /proc/sys/vm/overcommit_memory à sa valeur par défaut : , et pendant un certain temps je l'ai défini comme :1 , parce que je préférais que les programmes soient tués par le tueur OOM plutôt que de se comporter mal parce qu'ils ne vérifient pas les valeurs de retour de malloc lorsque les allocations sont refusées.
Quand je parlais de ce problème sur IRC , j'ai rencontré d'autres utilisateurs de Linux qui ont rencontré ce même problème, donc je suppose que beaucoup d'utilisateurs sont concernés par cela.
Pour moi, ce n'est pas acceptable car même Windows gère mieux l'utilisation élevée de la mémoire.
Si vous avez besoin de plus d'informations, avez une suggestion, s'il vous plaît dites-le moi.
Documentation :
https://en.wikipedia.org/wiki/Thrashing_%28computer_science%29
https://en.wikipedia.org/wiki/Memory_overcommitment
https://www. kernel.org/doc/Documentation/sysctl/vm.txt
https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
https://lwn.net/Articles/ 317814/
Ils en parlent :
Pourquoi le tueur Linux out-of-memory (OOM) ne s'exécute-t-il pas automatiquement, mais fonctionne sur la clé sysrq ?
Pourquoi OOM-killer échoue-t-il parfois à tuer les ressources gourmandes ?
Précharger OOM Killer
Est-il possible de déclencher OOM-killer lors d'un échange forcé ?
Comment éviter une latence élevée près d'une situation OOM ?
https://lwn.net/Articles/104179 /
https://bbs.archlinux.org/viewtopic.php?id=233843
Réponse acceptée :
J'ai trouvé deux explications (de la même chose) pour expliquer pourquoi kswapd0 fait la lecture constante du disque se produit bien avant que OOM-killer ne tue le processus incriminé :
- voir la réponse et le commentaire de cette réponse askubuntu SE
- voir la réponse et les commentaires de David Schwartz sur cette réponse sur unix SE
Je vais citer ici le commentaire de 1. qui m'a vraiment ouvert les yeux sur la raison pour laquelle j'obtenais une lecture constante du disque alors que tout était gelé :
Par exemple, considérez un cas où vous n'avez aucun échange et
le système est presque à court de RAM. Le noyau prendra de la mémoire, par exemple
Firefox (il peut le faire car Firefox exécute un code exécutable
qui a été chargé à partir du disque - le code peut être chargé à nouveau à partir du disque
si nécessaire). Si Firefox a ensuite besoin d'accéder à nouveau à cette RAM N
secondes plus tard, le CPU génère une "erreur matérielle" qui oblige Linux à
libérer de la RAM (par exemple, prendre de la RAM d'un autre processus), charger le
données manquantes sur le disque, puis laissez Firefox continuer comme d'habitude.
Ceci est assez similaire à l'échange normal et kswapd0 le fait. – Mikko
Rantalainen le 15 février à 13:08
Si quelqu'un a un moyen de désactiver ce comportement (peut-être recompiler le noyau avec quelles options ?), veuillez me le faire savoir dès que possible ! Très apprécié, merci !
MISE À JOUR : Le seul moyen que j'ai trouvé jusqu'à présent est de corriger le noyau, et cela fonctionne pour moi avec le swap désactivé (c'est-à-dire CONFIG_SWAP is not set ) mais ne fonctionne pas pour les autres avec le swap activé, semble-t-il ; voir le patch à l'intérieur de cette question.