Forensische Analyse des OOM-Killers

Ubuntus Out-Of-Memory-Killer hat auf meinem Server Chaos angerichtet und meine Anwendungen, Sendmail, Apache und andere stillschweigend ermordet.

Ich habe es geschafft zu erfahren, was der OOM Killer ist und über seine "Schlechtigkeits" -Regeln. Während mein Computer klein ist, sind meine Anwendungen noch kleiner und normalerweise wird nur die Hälfte meines physischen Speichers verwendet, geschweige denn der Swap-Space. Ich war also überrascht. Ich versuche, den Schuldigen herauszufinden, aber ich weiß nicht, wie ich die OOM-Killer-Protokolle lesen soll.

Kann mir jemand bitte zu einem Tutorial zeigen auf , wie die Daten in den Protokollen zu lesen (was sind ve, freeund gen?), Oder mir helfen , diese Protokolle zu analysieren?

Apr 20 20:03:27 EL135 kernel: kill_signal(13516.0): selecting to kill, queued 0, seq 1, exc 2326 0 goal 2326 0...
Apr 20 20:03:27 EL135 kernel: kill_signal(13516.0): task ebb0c6f0, thg d33a1b00, sig 1
Apr 20 20:03:27 EL135 kernel: kill_signal(13516.0): selected 1, signalled 1, queued 1, seq 1, exc 2326 0 red 61795 745
Apr 20 20:03:27 EL135 kernel: kill_signal(13516.0): selecting to kill, queued 0, seq 2, exc 122 0 goal 383 0...
Apr 20 20:03:27 EL135 kernel: kill_signal(13516.0): task ebb0c6f0, thg d33a1b00, sig 1
Apr 20 20:03:27 EL135 kernel: kill_signal(13516.0): selected 1, signalled 1, queued 1, seq 2, exc 383 0 red 61795 745
Apr 20 20:03:27 EL135 kernel: kill_signal(13516.0): task ebb0c6f0, thg d33a1b00, sig 2
Apr 20 20:03:27 EL135 kernel: OOM killed process watchdog (pid=14490, ve=13516) exited, free=43104 gen=24501.
Apr 20 20:03:27 EL135 kernel: OOM killed process tail (pid=4457, ve=13516) exited, free=43104 gen=24502.
Apr 20 20:03:27 EL135 kernel: OOM killed process ntpd (pid=10816, ve=13516) exited, free=43104 gen=24503.
Apr 20 20:03:27 EL135 kernel: OOM killed process tail (pid=27401, ve=13516) exited, free=43104 gen=24504.
Apr 20 20:03:27 EL135 kernel: OOM killed process tail (pid=29009, ve=13516) exited, free=43104 gen=24505.
Apr 20 20:03:27 EL135 kernel: OOM killed process apache2 (pid=10557, ve=13516) exited, free=49552 gen=24506.
Apr 20 20:03:27 EL135 kernel: OOM killed process apache2 (pid=24983, ve=13516) exited, free=53117 gen=24507.
Apr 20 20:03:27 EL135 kernel: OOM killed process apache2 (pid=29129, ve=13516) exited, free=68493 gen=24508.
Apr 20 20:03:27 EL135 kernel: OOM killed process sendmail-mta (pid=941, ve=13516) exited, free=68803 gen=24509.
Apr 20 20:03:27 EL135 kernel: OOM killed process tail (pid=12418, ve=13516) exited, free=69330 gen=24510.
Apr 20 20:03:27 EL135 kernel: OOM killed process python (pid=22953, ve=13516) exited, free=72275 gen=24511.
Apr 20 20:03:27 EL135 kernel: OOM killed process apache2 (pid=6624, ve=13516) exited, free=76398 gen=24512.
Apr 20 20:03:27 EL135 kernel: OOM killed process python (pid=23317, ve=13516) exited, free=94285 gen=24513.
Apr 20 20:03:27 EL135 kernel: OOM killed process tail (pid=29030, ve=13516) exited, free=95339 gen=24514.
Apr 20 20:03:28 EL135 kernel: OOM killed process apache2 (pid=20583, ve=13516) exited, free=101663 gen=24515.
Apr 20 20:03:28 EL135 kernel: OOM killed process logger (pid=12894, ve=13516) exited, free=101694 gen=24516.
Apr 20 20:03:28 EL135 kernel: OOM killed process bash (pid=21119, ve=13516) exited, free=101849 gen=24517.
Apr 20 20:03:28 EL135 kernel: OOM killed process atd (pid=991, ve=13516) exited, free=101880 gen=24518.
Apr 20 20:03:28 EL135 kernel: OOM killed process apache2 (pid=14649, ve=13516) exited, free=102748 gen=24519.
Apr 20 20:03:28 EL135 kernel: OOM killed process grep (pid=21375, ve=13516) exited, free=132167 gen=24520.
Apr 20 20:03:57 EL135 kernel: kill_signal(13516.0): selecting to kill, queued 0, seq 4, exc 4215 0 goal 4826 0...
Apr 20 20:03:57 EL135 kernel: kill_signal(13516.0): task ede29370, thg df98b880, sig 1
Apr 20 20:03:57 EL135 kernel: kill_signal(13516.0): selected 1, signalled 1, queued 1, seq 4, exc 4826 0 red 189481 331
Apr 20 20:03:57 EL135 kernel: kill_signal(13516.0): task ede29370, thg df98b880, sig 2
Apr 20 20:04:53 EL135 kernel: kill_signal(13516.0): selecting to kill, queued 0, seq 5, exc 3564 0 goal 3564 0...
Apr 20 20:04:53 EL135 kernel: kill_signal(13516.0): task c6c90110, thg cdb1a100, sig 1
Apr 20 20:04:53 EL135 kernel: kill_signal(13516.0): selected 1, signalled 1, queued 1, seq 5, exc 3564 0 red 189481 331
Apr 20 20:04:53 EL135 kernel: kill_signal(13516.0): task c6c90110, thg cdb1a100, sig 2
Apr 20 20:07:14 EL135 kernel: kill_signal(13516.0): selecting to kill, queued 0, seq 6, exc 8071 0 goal 8071 0...
Apr 20 20:07:14 EL135 kernel: kill_signal(13516.0): task d7294050, thg c03f42c0, sig 1
Apr 20 20:07:14 EL135 kernel: kill_signal(13516.0): selected 1, signalled 1, queued 1, seq 6, exc 8071 0 red 189481 331
Apr 20 20:07:14 EL135 kernel: kill_signal(13516.0): task d7294050, thg c03f42c0, sig 2

Watchdog ist eine Watchdog-Aufgabe, die im Leerlauf war. Nichts in den Protokollen deutet darauf hin, dass es seit Tagen etwas getan hat. Seine Aufgabe ist es, eine der Anwendungen neu zu starten, wenn sie stirbt, so etwas ironisch, dass sie als erste getötet wird.

Tail überwachte einige Protokolldateien. Es ist unwahrscheinlich, dass er wahnsinnig viel Gedächtnis verbraucht.

Der Apache-Webserver stellt Seiten nur ~~einer kleinen alten Dame zur Verfügung, die sie nur verwendet, um sonntags in die Kirche zu gelangen,~~ ein paar Entwickler, die im Bett geschlafen haben und seit einigen Wochen keine Seite auf der Website besucht haben. Der einzige Verkehr, den es haben könnte, ist von den Port-Scannern; Der gesamte Inhalt ist passwortgeschützt und nicht von irgendwoher verlinkt, sodass keine Spinnen interessiert sind.

Python führt zwei separate benutzerdefinierte Anwendungen aus. Nichts in den Protokollen deutet darauf hin, dass sie nicht wie gewohnt mitsummten. Eine davon war eine relativ junge Implementierung, die den Verdächtigen Nr. 1 macht. Es hat keine Datenstrukturen von Bedeutung und verwendet normalerweise nur etwa 8% der gesamten physischen RAW. Es hat sich seitdem nicht schlecht benommen.

Der Grep ist Verdächtiger Nr. 2 und derjenige, für den ich mich schuldig machen möchte, weil es ein einmaliger Befehl war. Der Befehl (der die Ausgabe eines grep -r an einen anderen grep weiterleitete) wurde mindestens 30 Minuten zuvor gestartet, und die Tatsache, dass er noch ausgeführt wurde, ist verdächtig. Ich hätte jedoch nicht gedacht, dass grep jemals eine signifikante Menge an Speicher verwenden würde. Es dauerte eine Weile, bis der OOM-Killer dazu kam, was darauf hindeutet, dass es nicht verrückt wurde, aber der OOM-Killer hörte auf, als er getötet wurde, was darauf hindeutete, dass es ein Erinnerungsschwein war, das schließlich die Blutlust des OOM-Killers befriedigte .

— Seltsames Denken
quelle

Mögliches Duplikat von serverfault.com/questions/134669/…

— Bis auf weiteres angehalten.

Ich hatte mir diese Frage angesehen und festgestellt, dass es sich nicht um ein Duplikat handelte. Er sucht nach allgemeinen Informationen über den OOM Killer, von denen ich glaube, dass ich vorbei bin. Ich suche nach spezifischen Informationen zum Lesen einiger Protokolldateien - insbesondere was einige Parameter bedeuten könnten.

— Oddthinking

Der folgende Thread kann für Sie hilfreich sein. serverfault.com/questions/134669

— vasco.debian

Obwohl Ihre Apps möglicherweise klein sind, möchte ich Sie fragen: Haben Sie Trendstatistiken auf Ihrem Server? Es kann nützlich sein, die Wachstumsmuster der Speichernutzung zu beobachten. ZB wird der Speicher über einen bestimmten Zeitraum auf einmal oder langsam aufgebraucht? Geschieht es immer zur gleichen Tageszeit? Auf dieser Grundlage haben Sie möglicherweise weitere Hinweise darauf, wo Sie suchen müssen. Ein Tool wie Munin ist einfach zu starten.

— Fred Clausen

@Fred: Wenn Sie den Flop-Schweiß der Panik von dieser drei Jahre alten Frage wegwischen, werden Sie sehen, dass ich nicht nach allgemeinen Anweisungen zum Debuggen gefragt habe, sondern explizit nach den Hinweisen, die ich vom OOM Killer erhalten könnte Protokolle. Ich glaube, die Protokolldatei erklärt viel darüber, was in dieser nebligen Nacht passiert ist, aber es sind keine Übersetzungen verfügbar, um zu erklären, was darin steht, ohne Unmengen von Quellcode für den Linux-Kern zu lesen.

— Oddthinking

Ich bin neu bei ServerFault und habe gerade diesen Beitrag gesehen. Es scheint in der Nähe der Vorderseite der Warteschlange wieder aufgetaucht zu sein, obwohl es alt ist. Lassen Sie uns diese beängstigende vielleicht ins Bett bringen?

Zunächst einmal interessiere ich mich für dieses Thema, da ich Systeme mit begrenztem RAM optimiere, um viele Benutzerprozesse auf sichere Weise auszuführen.

Ich bin der Meinung, dass sich die Fehlermeldungen in diesem Protokoll auf OpenVZ Linux-Container beziehen.

Ein "ve" ist eine virtuelle Umgebung und wird in OpenVZ auch als Container bezeichnet. Jeder Container erhält eine ID und die angezeigte Nummer ist diese ID. Mehr dazu hier:

https://openvz.org/Container

Der Begriff "frei" bezieht sich auf den freien Speicher in Bytes zu diesem Zeitpunkt. Sie können sehen, dass der freie Speicher allmählich zunimmt, wenn Prozesse beendet werden.

Der Begriff "gen" ist mir etwas unsicher. Ich glaube, das bezieht sich auf die Generation. Das heißt, es beginnt bei 1 und erhöht sich für jede Generation eines Prozesses in einem Container um eins. Für Ihr System scheinen also seit dem Start mehr als 24.000 Prozesse ausgeführt worden zu sein. Bitte korrigieren Sie mich, wenn ich falsch liege. Das sollte leicht zu testen sein.

Der Grund, warum Prozesse abgebrochen wurden, liegt an Ihrer OOM-Killer-Konfiguration. Es wird versucht, den freien Speicher auf die erwartete Menge zurückzubringen (die anscheinend 128 KB beträgt). Oracle hat eine gute Beschreibung, wie Sie dies so konfigurieren können, dass es Ihnen besser gefällt:

http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html

Wenn Sie außerdem die Speicherkonfiguration für jeden Ihrer Container anzeigen möchten, überprüfen Sie Folgendes:

https://openvz.org/Setting_UBC_parameters

— Zahnon
quelle