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 des heures, voire des jours , au lieu de tuer des processus pour libérer la mémoire.
Le maximum que j'ai enregistré est de 7 jours avant de me résigner pour effectuer une réinitialisation.
Lorsque la MOO est sur le point d'être atteinte, l' iowait 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) depuis 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 un ArchLinux actualisé (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 version mise à jour de Debian 9.6 (4.9.0), j'ai 16 Go de RAM physique, un SSD sur lequel mon système d'exploitation est installé et pas de partition de swap .
En raison de la quantité de RAM que j'ai, je ne veux pas activer une partition de swap, car cela retarderait simplement l'apparition du problème.
De plus, le remplacement trop fréquent des disques SSD pourrait potentiellement réduire la durée de vie du disque.
Soit dit en passant, j'ai déjà essayé avec et sans partition de swap, il s'est avéré ne faire que retarder l'apparition du problème, mais ce n'est pas la solution.
Pour moi, le problème est dû au 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 normalement ne lisent 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'un devait être réglé /proc/sys/vm/min_free_kbytes
sur 1000000
(1 Go).
Parce que ces 1 Go devraient rester libres, je pensais que cette mémoire serait réservée par Linux pour mettre en cache des données importantes.
Mais cela n'a pas fonctionné.
En outre, je pense utile d'ajouter que même si cela peut sembler très bien en théorie, restreindre la taille de la mémoire virtuelle à la taille de la mémoire physique, en définissant ce /proc/sys/vm/overcommit_memory
qui 2
n'est pas décemment techniquement possible dans ma situation, car le type d'applications que j'utilise, nécessitent plus de mémoire virtuelle qu'ils n'en utilisent effectivement pour certaines raisons.
Selon le fichier /proc/meminfo
, la Commited_AS
valeur est souvent supérieure au double du RAM physique sur 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:, 0
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 incorrectement car ils ne vérifient pas les valeurs de retour de malloc
quand les allocations sont refusées.
Lorsque je parlais de ce problème sur IRC , j'ai rencontré d'autres utilisateurs 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 une utilisation élevée de la mémoire.
Si vous avez besoin de plus d'informations, avez une suggestion, 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 hors mémoire (OOM) ne s'exécute-t-il pas automatiquement, mais fonctionne sur sysrq-key?
Pourquoi le tueur OOM ne parvient-il pas parfois à tuer les porcs de ressources?
Préchargement de l'OOM Killer
Est-il possible de déclencher OOM-killer lors d'un échange forcé?
Comment éviter une latence élevée près de la situation OOM?
https://lwn.net/Articles/104179/
https://bbs.archlinux.org/viewtopic.php?id=233843
min_free_kbytes
n'est pas pertinent, ce n'est pas une réserve pour les pages en cache. AFAICT aucun des sysctls vm ne permet de réserver de mémoire spécifiquement pour les pages en cache, c'est-à-dire de limiter les allocations MAP_ANONYMOUS :(.