Comment tester Oom-killer depuis la ligne de commande ?

Le tueur OOM ou Out Of Memory Tueur est un processus que
linux que le noyau emploie lorsque le système manque cruellement de mémoire. … Cela maximise l'utilisation de la mémoire système en garantissant que la
mémoire allouée aux processus est activement utilisée.

Cette question à réponse automatique demande :

• Comment tester oom-killer depuis la ligne de commande ?

Une méthode plus rapide que la demi-heure qu'il faut pour l'auto-réponse serait acceptée.

Réponse acceptée :

La clé pour déclencher rapidement le tueur OOM est d'éviter de s'enliser dans les accès au disque. Donc :

1. Évitez l'échange, sauf si votre objectif est spécifiquement de tester le comportement de OOM lorsque l'échange est utilisé. Vous pouvez désactiver le swap avant le test, puis le réactiver après. swapon -s vous indique quels swaps sont actuellement activés. sudo swapoff -a désactive tous les swaps ; sudo swapon -a est généralement suffisant pour les réactiver.

2. Évitez d'entremêler les accès à la mémoire avec des accès au disque non swap. Cette méthode basée sur la globalisation finit par utiliser votre mémoire disponible (étant donné suffisamment d'entrées dans votre système de fichiers), mais la raison pour laquelle elle a besoin de tant de mémoire est de stocker les informations qu'elle obtient en accédant à votre système de fichiers. Même avec un SSD, il est probable qu'une grande partie du temps soit consacrée à la lecture à partir du disque, même si l'échange est désactivé. Si votre objectif est spécifiquement de tester le comportement du MOO pour les accès mémoire entrecoupés d'accès disque, cette méthode est raisonnable, voire idéale. Sinon, vous pouvez atteindre votre objectif beaucoup plus rapidement.

Une fois que vous avez désactivé le swap, toute méthode qui lit rarement à partir d'un disque physique devrait être assez rapide. Cela inclut la tail /dev/zero (trouvé par falstaff, commenté ci-dessus par Doug Smythies). Bien qu'il lise à partir du périphérique de caractères /dev/zero , ce "périphérique" ne génère que des octets nuls (c'est-à-dire des octets entièrement composés de zéros) et n'implique aucun accès au disque physique une fois que le nœud du périphérique a été ouvert. Cette méthode fonctionne car tail recherche les lignes de fin dans son entrée, mais un flux de zéros ne contient aucun caractère de nouvelle ligne, il n'obtient donc jamais de lignes à supprimer.

Si vous recherchez un one-liner dans un langage interprété qui alloue et remplit la mémoire de manière algorithmique, vous avez de la chance. Dans à peu près n'importe quel langage interprété à usage général, il est facile d'allouer beaucoup de mémoire et d'y écrire sans l'utiliser autrement. Voici un one-liner Perl qui semble être à peu près aussi rapide que tail /dev/zero (bien que je ne l'aie pas beaucoup comparé):

perl -wE 'my @xs; for (1..2**20) { push @xs, q{a} x 2**20 }; say scalar @xs;'

Avec le swap désactivé sur une ancienne machine avec 4 Go de RAM, à la fois cela et tail /dev/zero a pris environ dix secondes à chaque fois que je les ai exécutés. Les deux devraient toujours fonctionner correctement sur les machines les plus récentes avec beaucoup plus de RAM que cela. Vous pouvez faire ce perl commande beaucoup plus courte, si votre objectif est la brièveté.

Ce one-liner Perl génère à plusieurs reprises (q{a} x 2**20 ) séparent les chaînes modérément longues (environ un million de caractères chacune) et les conservent en les stockant dans un tableau (@xs ). Vous pouvez ajuster les nombres pour les tests. Si vous n'utilisez pas toute la mémoire disponible, le one-liner affiche le nombre total de chaînes créées. En supposant que le tueur OOM tue perl – avec la commande exacte indiquée ci-dessus et aucun quota de ressources pour gêner, je pense qu'en pratique, cela sera toujours le cas – alors votre shell devrait vous montrer Killed . Ensuite, comme dans toute situation de MOO, dmesg a les détails.

En relation :Que doit contenir une liste de contrôle DVT (Design Verification Test) ?

Bien que j'aime cette méthode, elle illustre quelque chose d'utile sur l'écriture, la compilation et l'utilisation d'un programme C, comme celui de la réponse de Doug Smythies. L'allocation de mémoire et l'accès à la mémoire ne semblent pas être des choses distinctes dans les langages interprétés de haut niveau, mais en C, vous pouvez remarquer et, si vous le souhaitez, étudier ces détails.

Enfin, vous devez toujours vérifier que le tueur de MOO est bien celui qui a tué votre programme . Une façon de vérifier est d'inspecter dmesg . Contrairement à la croyance populaire, il est en fait possible qu'une tentative d'allocation de mémoire échoue rapidement, même sous Linux. Il est facile d'y parvenir avec d'énormes allocations qui échoueront évidemment… mais même celles-ci peuvent se produire de manière inattendue. Et des allocations apparemment raisonnables peuvent échouer rapidement. Par exemple, sur ma machine de test, perl -wE 'say length q{a} x 3_100_000_000;' réussit, et perl -wE 'say length q{a} x 3_200_000_000;' imprime :

Out of memory!
panic: fold_constants JMPENV_PUSH returned 2 at -e line 1.

Ni l'un ni l'autre n'a déclenché le tueur OOM. Plus généralement :

• Si votre programme précalcule la quantité de mémoire nécessaire et la demande en une seule allocation, l'allocation peut réussir (et si c'est le cas, le tueur de MOO peut ou non tuer le programme lorsqu'une quantité suffisante de mémoire est utilisée), ou l'allocation peut simplement échouer.
• Étendre un tableau à une longueur énorme en y ajoutant de très nombreux éléments déclenche souvent le tueur de MOO dans la pratique réelle, mais en le faisant faire de manière fiable dans les tests est étonnamment délicat. La façon dont cela est presque toujours fait - parce que c'est la façon la plus efficace de le faire - est de faire de chaque nouveau tampon une capacité x fois la capacité de l'ancien tampon. Valeurs communes pour x comprennent 1,5 et 2 (et la technique est souvent appelée "doublement de table"). Cela comble parfois l'écart entre la quantité de mémoire qui peut réellement être allouée et utilisée et la quantité que le noyau sait être trop importante pour même faire semblant de la distribuer.
• Les allocations de mémoire peuvent échouer pour des raisons qui n'ont rien à voir avec le noyau ou la quantité de mémoire réellement disponible, et cela ne déclenche pas non plus le tueur de MOO. En particulier, un programme peut échouer rapidement sur une allocation de n'importe quelle taille après avoir effectué avec succès un très grand nombre de minuscules allocations. Cet échec se produit dans la comptabilité effectuée par le programme lui-même, généralement via une bibliothèque comme malloc() . Je soupçonne que c'est ce qui m'est arrivé aujourd'hui lorsque, lors des tests avec bash tableaux (qui sont en fait implémentés sous forme de listes doublement chaînées), bash quitter avec un message d'erreur disant une allocation de 9 octets échoué.

Le tueur OOM est beaucoup plus facile à déclencher accidentellement qu'à déclencher intentionnellement.

En essayant de déclencher délibérément le tueur OOM, une façon de contourner ces problèmes est de commencer par demander trop de mémoire, et de diminuer progressivement, comme le fait le programme C de Doug Smythies. Une autre façon consiste à allouer tout un tas de blocs de mémoire de taille moyenne, ce que fait le one-liner Perl illustré ci-dessus :aucune des chaînes de caractères millionnaires (plus un peu d'utilisation supplémentaire de la mémoire dans les coulisses) n'est particulièrement éprouvante, mais pris ensemble, tous les achats d'un mégaoctet s'additionnent.