OOM killer ne fonctionne pas correctement, conduit à un système d'exploitation gelé


23

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: iotopa 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_kbytessur 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_memoryqui 2n'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_ASvaleur 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_memorysa valeur par défaut:, 0et pendant un certain temps, je l'ai défini comme:, 1parce 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 mallocquand 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


1
Je pense que c'est ce à quoi vous devez vous attendre, si vous êtes débordant, mais vous n'approchez pas vraiment à 100% "utilisé", c'est-à-dire qu'il y a trop d'utilisation de la mémoire qui est sauvegardée sur fichier, comptée comme "buff / cache". (Ugh, cette formulation suppose que vos allocations tmpfs sont triviales, car elles apparaissent comme "buff / cache", mais ne peuvent pas être paginées vers un système de fichiers physique). min_free_kbytesn'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 :(.
sourcejedi

2
Je cherche depuis des années une solution à ce problème précis sans succès. Je crois que j'ai d'abord remarqué le problème après avoir remplacé mon disque dur par un SSD, ce qui m'a également obligé à désactiver complètement l'échange, mais je ne peux pas vraiment garantir que cela ne s'est jamais produit avant ces changements, donc cela pourrait ne pas être lié. Je suis sur Archlinux btw.
brunocodutra

2
Je viens de poster sur les forums Arch Linux à ce sujet.
Ignat Insarov

1
@ dsstorefile1 Merci, je vais essayer ça. Mais comment pourrait-il déclencher le tueur OOM avec certitude lorsque le noyau dans cette situation ne peut pas le faire correctement?
M89

1
Cela a aidé lorsque Chrome a réussi à s'infiltrer dans toute ma RAM ... (Bien que j'ai finalement ajouté une partition de swap de disque et également mis à niveau vers une quantité décente de RAM)
Gert van den Berg

Réponses:


5

Je l' ai trouvé deux explications (la même chose) pour expliquer pourquoi kswapd0 ne lecture de disque constant se produit bien avant OOM tueur tue le processus incriminé:

  1. voir la réponse et le commentaire de cette réponse askubuntu SE
  2. 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 de disque constante alors que tout était gelé :

Par exemple, considérons un cas où vous avez zéro échange et le système est presque à court de RAM. Le noyau prendra de la mémoire par exemple de Firefox (il peut le faire car Firefox exécute du 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 les données manquantes du disque et ensuite permettre à Firefox de continuer comme habituel. Ceci est assez similaire au swapping normal et kswapd0 le fait. - Mikko Rantalainen 15 février à 13h08

Si quelqu'un a un moyen de désactiver ce comportement (peut-être recompiler le noyau avec quelles options? ), Faites-le moi savoir dès que possible! Très apprécié, merci!

MISE À JOUR: Le seul moyen que j'ai trouvé jusqu'à présent est de patcher 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é, il semble ; voir le patch à l'intérieur de cette question.


Veuillez supprimer le texte non valide. Ne marquez pas les modifications avec "MODIFIER" dans le texte. Ils ressortent clairement de l' historique des révisions .
Kusalananda

1
@Kusalananda Cet utilisateur doit être encouragé car il est probablement celui qui a le plus contribué.
M89

@Kusalananda J'ai pensé qu'il était important de les garder pour que les autres puissent voir ce que (d'autre) avait essayé et ne fonctionnait pas. Peut-être UPDATEqu'au lieu de EDITça aurait été mieux?

@MarcusLinsner Non, désolé, vous avez mal compris. Montrer ce que vous avez essayé, c'est ce que vous faites lorsque vous posez une question. La réponse doit être correcte pour la question telle qu'elle est actuellement posée. Je veux dire, une modification demande même au lecteur d' ignorer les modifications précédentes . Si l'on souhaite voir l'historique des modifications, vous pouvez le voir ici .
Kusalananda

0

Le memory.minparamètre dans le cgroups-v2contrôleur de mémoire devrait aider.

À savoir, permettez-moi de citer:

Protection de la mémoire dure. Si l'utilisation de la mémoire d'un groupe de contrôle se situe dans sa limite minimale effective, la mémoire du groupe de contrôle ne sera en aucun cas récupérée. S'il n'y a pas de mémoire récupérable non protégée disponible, OOM killer est appelé.

Source: https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html


Pourriez-vous élaborer, s'il vous plaît? Votre réponse est un peu courte pour répondre à la question OP.
Paradox
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.