Wie teste ich Oom-Killer über die Befehlszeile?

Der OOM-Killer oder Out Of Memory Killer ist ein Prozess, den das
linux Kernel verwendet, wenn das System kritisch wenig Arbeitsspeicher hat. … Dadurch wird die Nutzung des Systemspeichers maximiert, indem sichergestellt wird, dass der
Prozessen zugewiesene Speicher aktiv genutzt wird.

Diese selbstbeantwortete Frage lautet:

• Wie teste ich oom-killer von der Kommandozeile aus?

Eine schnellere Methode als die 1/2 Stunde, die für die Selbstantwort benötigt wird, würde akzeptiert werden.

Akzeptierte Antwort:

Der Schlüssel zum schnellen Auslösen des OOM-Killers besteht darin, sich nicht durch Festplattenzugriffe festfahren zu lassen. Also:

1. Vermeiden Sie Auslagerungen, es sei denn, Sie möchten speziell das Verhalten von OOM testen, wenn Auslagerungen verwendet werden. Sie können Swap vor dem Test deaktivieren und danach wieder aktivieren. swapon -s sagt Ihnen, welche Swaps derzeit aktiviert sind. sudo swapoff -a deaktiviert alle Swaps; sudo swapon -a reicht in der Regel aus, sie wieder zu aktivieren.

2. Vermeiden Sie es, Speicherzugriffe mit Nicht-Swap-Festplattenzugriffen zu vermischen. Diese auf Globbing basierende Methode verbraucht schließlich Ihren verfügbaren Speicher (bei genügend Einträgen in Ihrem Dateisystem), aber der Grund, warum sie so viel Speicher benötigt, ist das Speichern von Informationen, die sie durch den Zugriff auf Ihr Dateisystem erhält. Selbst bei einer SSD wird wahrscheinlich viel Zeit mit dem Lesen von der Festplatte verbracht, selbst wenn Swap deaktiviert ist. Wenn Ihr Ziel speziell darin besteht, das OOM-Verhalten für Speicherzugriffe zu testen, die mit Plattenzugriffen durchsetzt sind, ist diese Methode sinnvoll, vielleicht sogar ideal. Sonst kommen Sie viel schneller ans Ziel.

Sobald Sie Swap deaktiviert haben, sollte jede Methode, die selten von einer physischen Festplatte liest, ziemlich schnell sein. Dazu gehört tail /dev/zero (gefunden von falstaff, oben kommentiert von Doug Smythies). Obwohl es vom Zeichengerät /dev/zero liest , generiert dieses „Gerät“ nur Nullbytes (d. h. Bytes nur aus Nullen) und beinhaltet keinen physischen Festplattenzugriff, sobald der Geräteknoten geöffnet wurde. Diese Methode funktioniert, weil tail sucht nach nachgestellten Zeilen in seiner Eingabe, aber ein Strom von Nullen enthält kein Zeilenumbruchzeichen, sodass keine Zeilen verworfen werden müssen.

Wenn Sie nach einem Einzeiler in einer interpretierten Sprache suchen, die den Speicher algorithmisch zuweist und füllt, haben Sie Glück. In fast jeder interpretierten Allzwecksprache ist es einfach, viel Speicher zuzuweisen und darauf zu schreiben, ohne ihn anderweitig zu verwenden. Hier ist ein Perl-Einzeiler, der ungefähr so ​​schnell zu sein scheint wie tail /dev/zero (obwohl ich es nicht ausgiebig bewertet habe):

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

Bei ausgeschaltetem Swap auf einer alten Maschine mit 4 GiB RAM, sowohl das als auch tail /dev/zero Jedes Mal, wenn ich sie durchführte, dauerte es ungefähr zehn Sekunden. Beide sollten auf neueren Maschinen mit viel mehr RAM noch gut funktionieren. Sie können das perl machen Befehl viel kürzer, wenn Ihr Ziel Kürze ist.

Dieser Perl-Einzeiler generiert wiederholt (q{a} x 2**20 ) trennt mäßig lange Zeichenfolgen – jeweils etwa eine Million Zeichen – und hält sie überall, indem sie in einem Array gespeichert werden (@xs ). Sie können die Zahlen zum Testen anpassen. Wenn Sie nicht den gesamten verfügbaren Speicher verwenden, gibt der Einzeiler die Gesamtzahl der erstellten Zeichenfolgen aus. Angenommen, der OOM-Killer tötet perl – mit genau dem oben gezeigten Befehl und ohne Ressourcenkontingente, die im Weg stehen, glaube ich, dass es in der Praxis immer so sein wird – dann sollte Ihre Shell Ihnen Killed anzeigen . Dann, wie in jeder OOM-Situation, dmesg hat die Details.

Obwohl ich diese Methode mag, veranschaulicht sie etwas Nützliches über das Schreiben, Kompilieren und Verwenden eines C-Programms – wie das in der Antwort von Doug Smythies. Das Zuweisen von Speicher und der Zugriff auf den Speicher fühlen sich in hochgradig interpretierten Sprachen nicht wie getrennte Dinge an, aber in C können Sie diese Details bemerken und, wenn Sie möchten, untersuchen.

Schließlich sollten Sie immer prüfen, ob der OOM-Killer tatsächlich Ihr Programm zerstört hat . Eine Möglichkeit zur Überprüfung besteht darin, dmesg zu inspizieren . Entgegen der landläufigen Meinung ist es tatsächlich möglich, dass ein Versuch, Speicher zuzuweisen, sogar unter Linux schnell fehlschlägt. Es ist einfach, dies mit riesigen Allokationen zu erreichen, die offensichtlich fehlschlagen werden … aber selbst diese können unerwartet passieren. Und scheinbar vernünftige Allokationen können schnell scheitern. Beispiel:Auf meiner Testmaschine perl -wE 'say length q{a} x 3_100_000_000;' erfolgreich ist, und perl -wE 'say length q{a} x 3_200_000_000;' druckt:

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

Weder löste den OOM-Killer aus. Allgemeiner gesprochen:

• Wenn Ihr Programm vorausberechnet, wie viel Speicher benötigt wird, und danach in einer einzigen Zuweisung fragt, kann die Zuweisung erfolgreich sein (und wenn dies der Fall ist, kann der OOM-Killer das Programm beenden oder auch nicht, wenn genügend Speicher verwendet wird). oder die Zuordnung schlägt einfach fehl.
• Ein Array auf eine enorme Länge zu erweitern, indem viele, viele Elemente hinzugefügt werden, löst in der Praxis oft den OOM-Killer aus, aber dafür zuverlässig beim Testen ist überraschend knifflig. Dies geschieht fast immer – weil es am effizientesten ist – indem jeder neue Puffer mit einer Kapazität von x erstellt wird mal die Kapazität des alten Puffers. Übliche Werte für x gehören 1,5 und 2 (und die Technik wird oft als „Tabellenverdopplung“ bezeichnet). Dies überbrückt manchmal die Lücke zwischen dem, wie viel Speicher tatsächlich zugewiesen und verwendet werden kann, und dem, wie viel der Kernel zu viel weiß, um sich auch nur die Mühe zu machen, so zu tun, als würde er es verteilen.
• Speicherzuweisungen können aus Gründen fehlschlagen, die wenig mit dem Kernel zu tun haben oder wie viel Speicher tatsächlich verfügbar ist, und das löst auch nicht den OOM-Killer aus. Insbesondere kann ein Programm bei einer Zuweisung beliebiger Größe schnell fehlschlagen, nachdem es erfolgreich eine sehr große Anzahl winziger Zuweisungen durchgeführt hat. Dieser Fehler tritt in der Buchhaltung auf, die vom Programm selbst durchgeführt wird – normalerweise durch eine Bibliothekseinrichtung wie malloc() . Ich vermute, das ist mir heute beim Testen mit bash passiert Arrays (die eigentlich als doppelt verknüpfte Listen implementiert sind), bash Beenden mit einer Fehlermeldung, die eine Zuweisung von 9 Bytes besagt fehlgeschlagen.

Der OOM-Killer lässt sich viel leichter versehentlich auslösen als absichtlich.

Bei dem Versuch, den OOM-Killer absichtlich auszulösen, besteht eine Möglichkeit, diese Probleme zu umgehen, darin, zu viel Speicher anzufordern und allmählich kleiner zu werden, wie es das C-Programm von Doug Smythies tut. Eine andere Möglichkeit besteht darin, einen ganzen Haufen mittelgroßer Speicherblöcke zuzuweisen, was der oben gezeigte Perl-Einzeiler tut:Keine der millionenschweren Zeichenketten (plus etwas zusätzlicher Speicherverbrauch hinter den Kulissen) ist besonders anstrengend, aber zusammengenommen summieren sich alle Ein-Megabyte-Käufe.