OOM Killer triggert nicht bzw zu spät

Welches Modul/Treiber für welche Hardware, Kernel compilieren...
Antworten
Benutzeravatar
king-crash
Beiträge: 720
Registriert: 08.08.2006 12:07:56
Lizenz eigener Beiträge: MIT Lizenz

OOM Killer triggert nicht bzw zu spät

Beitrag von king-crash » 28.09.2022 09:09:40

Hallo,

Mein System wird bei erreichen des maximalen Arbeitsspeichers unbenutzbar. Es gibt zeitweise keine Reaktionen der Maus mehr und auch die Num-LED lässt sich nicht mehr toggeln. Ich benutze keinen SWAP.
Eigentlich würde ich im Sinne der Betriebssicherheit erwarten, dass der OOM Killer aufräumt bevor es zu derartigen Einschränkungen kommt. Ich kann diesen Zustand mit folgendem Programm nachstellen (-M Option muss an den vorhandenen Speicher angepasst werden, ich habe 16GB):

Code: Alles auswählen

stressapptest -s 20 -M 13800 -W -m 8 -C 8
Wähle ich den Wert so, dass fast kein Speicher mehr übrig bleibt, aber der maximal Verfügbare Wert auch nicht überschritten wird, schreitet der OOM Killer nicht ein und es kommt zur vorübergehenden Unbenutzbarkeit.

Kann ich den OOM Killer so konfigurieren, dass er bereits bei sagen wir 95% RAM Auslastung aktiv wird?
Oder kennt jemand eine andere Lösung?

Grüße

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: OOM Killer triggert nicht bzw zu spät

Beitrag von Tintom » 28.09.2022 09:53:55

Ich hatte hier ein ähnliches Problem, bei 4 GB RAM und mehreren offenen Tabs hat der Firefox den Hauptspeicher rasant verschlungen, der OOM-Killer wurde aus mir unerklärlichen Gründen nie aktiv. Die Kunst lag darin den Fehler überhaupt erst einmal zu lokalisieren, denn wenn plötzlich und ohne Vorwarnung das System stehen bleibt sitzt man ratlos vor dem Rechner. Ich hatte etwa wochenlang den Kernel im Verdacht, auf den RAM bin ich zunächst nicht gekommen.

Ich habe mir zunächst beholfen, indem ich ein einfaches Skript habe laufen lassen, welches die Arbeitsspeicherbelegung aus /proc/meminfo ausliest und ab einem kritischen Level dann Aktionen ausführt wie etwa mittels ps die speicherhungristen Prozesse anzeigen lassen. Dadurch konnte ich den Fehler lokalisieren (Firefox), aber die ständig aufploppenden Fenster wurden dann nervig. Ich bin dann später auf akustische Warnungen übergegangen und hab mir mittels Debianfestival vom System Warnmeldungen vorlesen lassen. Bei Interesse kann ich beide Varianten hier noch einstellen.

Die Lösung besteht aber darin dem System zusätzlichen Speicher zu gönnen, entweder in Form von RAM oder Swap. Da ich bereits den maximalen Ausbau an RAM habe, kam ein Aufrüsten nicht in Frage. Blieb also nur Swap, doch auch hier wollte ich nicht, dass das System dauerhaft Daten auf meine SSD auslagert. Zufällig bin ich dann auf das Kernelmodul zram gestoßen. Mittels zram ist es möglich einen Teil des RAM als komprimierte Ramdisk zu verwenden. Was zunächst kontraproduktiv erscheint (warum sollte man den knappen RAM zusätzlich verknappen?), wird bei näherer Betrachtung interessant: Durch die effizienten Algorithmen von zram wird ein Kompressionsverhältnis von bis zu 2:1 erreicht (lt. [1], persönlich komme ich auf noch höhere Werte), was bedeutet, dass eine 1 GB Ramdisk im Speicher effektiv 2 GB Daten fassen kann. Wenn man nun auf dieser Ramdisk einen Swapspeicher ablegt, kann man die Vorteile einer Ramdisk (Geschwindigkeit) mit dem eines Swaps (Speichererweiterung) verbinden und bekommt so mehr Speicherreserven auch auf bereits betagten Systemen. Der Nachteil an dieser Lösung ist, man erkauft sich diese Erweiterung mit zusätzlicher Rechenleistung, da jedes MB welches im Swap landet vom Prozessor ge- bzw. entpackt werden muss. Ich habe hier ein Dualcoresystem und merke das Auslagern in den Swap lediglich durch das Anspringen des CPU-Lüfters, sonst kann ich keine Verzögerungen feststellen. Bei zram kannst du entweder etwas eigenes basteln ([1], [2]) oder du verwendest das bereits in Debian enthaltene Paket Debianzram-tools, welches bereits alles vorbereitet hat und du es nur entsprechend deiner Wünsche konfigurieren musst.

[1] https://docs.kernel.org/admin-guide/blockdev/zram.html
[2] https://wiki.gentoo.org/wiki/Zram

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: OOM Killer triggert nicht bzw zu spät

Beitrag von hikaru » 28.09.2022 10:08:22

Prinzipiell könntest du /proc/sys/vm/overcommit_memory auf "2" setzen und dann über /proc/sys/vm/overcommit_ratio festlegen, wie viel RAM maximal von Programmen alloziert werden kann.
Das sollte dein System vor dem OOM-Killer-Freeze retten, hat aber mitunter "lustige" Effekte bei einzelnen Anwendungen. Als ich z.B. gerade zum Test für diesen Beitrag overcommit_memory auf dem Notebook neben mir auf 2 gesetzt habe (noch ohne overcommit_ratio zu ändern), starb sofort mein X-Server, obwohl eigentlich mehr als genug RAM frei ist. Der Cache war wohl voll.

Letztendlich hilft nur mehr RAM, oder zumindest Swap. Möglicherweise könnte dir Debianzram-tools ein Stück weiter helfen, aber auch hier solltest du mit unerwarteten Effekten rechnen. Z.B. habe ich instabiles Verhalten von VBox-VMs beobachtet, wenn Teile des Gast-RAM im Host-zram-Swap ausgelagert wurden.
Ich habe letztes Jahr meinem inzwischen recht betagten Desktop-PC (Sandy Bridge) noch ein Upgrade auf 32GB RAM gegönnt, nachdem ich mich zunächst ebenfalls mit dem OOM-Killer, dann notgedrungen ein paar Monate mit Swap und schließlich der Frage rumgeplagt hatte, ob ich den ganzen Rechner ersetzen soll.

Benutzeravatar
king-crash
Beiträge: 720
Registriert: 08.08.2006 12:07:56
Lizenz eigener Beiträge: MIT Lizenz

Re: OOM Killer triggert nicht bzw zu spät

Beitrag von king-crash » 28.09.2022 10:53:02

Die Menge an RAM ist absolut ausreichend. Das Problem besteht nur, wenn ich eine VM vergesse oÄ. Ich möchte in diesem Fall, dass ein Programm oder auch die VM abgeschossen wird.
Es geht mir um das Verhalten im Fehlerfall.
Auch ein Vergrößern von /proc/sys/vm/min_free_kbytes bringt keine Besserung. Was mich daran besonders stört ist, dass jeder Benutzer das System unbenutzbar machen kann ohne dass der OOM jemals anschlägt. Wie wird das bei Hostern gehandhabt, bei denen man keine VM sondern einen SSH Zugang hat?

Benutzeravatar
schorsch_76
Beiträge: 2535
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: OOM Killer triggert nicht bzw zu spät

Beitrag von schorsch_76 » 28.09.2022 11:02:56

Hier ist eine sehr ausführliche Erklärung dazu :)

https://www.lug-erding.de/blog/2020-05- ... emory.html

Benutzeravatar
schorsch_76
Beiträge: 2535
Registriert: 06.11.2007 16:00:42
Lizenz eigener Beiträge: MIT Lizenz

Re: OOM Killer triggert nicht bzw zu spät

Beitrag von schorsch_76 » 28.09.2022 11:05:03

king-crash hat geschrieben: ↑ zum Beitrag ↑
28.09.2022 10:53:02
Die Menge an RAM ist absolut ausreichend. Das Problem besteht nur, wenn ich eine VM vergesse oÄ. Ich möchte in diesem Fall, dass ein Programm oder auch die VM abgeschossen wird.
Es geht mir um das Verhalten im Fehlerfall.
Auch ein Vergrößern von /proc/sys/vm/min_free_kbytes bringt keine Besserung. Was mich daran besonders stört ist, dass jeder Benutzer das System unbenutzbar machen kann ohne dass der OOM jemals anschlägt. Wie wird das bei Hostern gehandhabt, bei denen man keine VM sondern einen SSH Zugang hat?
Die haben Swap ;)

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: OOM Killer triggert nicht bzw zu spät

Beitrag von hikaru » 28.09.2022 11:24:05

king-crash hat geschrieben: ↑ zum Beitrag ↑
28.09.2022 10:53:02
Die Menge an RAM ist absolut ausreichend.
Die Existenz dieses Threads lässt etwas anderes vermuten. ;)
king-crash hat geschrieben: ↑ zum Beitrag ↑
28.09.2022 10:53:02
Das Problem besteht nur, wenn ich eine VM vergesse oÄ. Ich möchte in diesem Fall, dass ein Programm oder auch die VM abgeschossen wird.
Es geht mir um das Verhalten im Fehlerfall.
Wie soll denn der Kernel den Fehlerfall erkennen? Oder anders gefragt: Was zeichnet eine "vergessene" VM gegenüber einer "normalen" VM aus?
Wenn du dafür knallharte technische Kriterien formulieren kannst (N Stunden keine Tastatur-Inputs o.Ä.), dann kannst du vemutlich auch einen Mechanismus basteln, der sie automatisch, und v.A. kontrolliert beendet.
king-crash hat geschrieben: ↑ zum Beitrag ↑
28.09.2022 10:53:02
Was mich daran besonders stört ist, dass jeder Benutzer das System unbenutzbar machen kann ohne dass der OOM jemals anschlägt.
Dann ist das also ein Mehrbenutzersystem, vulgo: "ein Server"? Und darauf laufen VMs (Mehrzahl)? Dann halte ich 16GB RAM tatsächlich für tendenziell knapp.
Gegen vergessene VMs auf einem Desktop-PC würde ich empfehlen, eine gut sichtbare(!) RAM-Füllstandsanzeige einzuführen.

Benutzeravatar
king-crash
Beiträge: 720
Registriert: 08.08.2006 12:07:56
Lizenz eigener Beiträge: MIT Lizenz

Re: OOM Killer triggert nicht bzw zu spät

Beitrag von king-crash » 28.09.2022 11:37:31

Ich habe jetzt gerade zum Testen overcommit auf "2 = aus" gesetzt und jetzt bringt stessapptest ab 4,1GB Fehler. Es sollten aber gute 12GB frei sein. Auch den cache (echo 1 > /proc/sys/vm/drop_caches) habe ich bereits geleert.
Log: Commandline - stressapptest -s 20 -M 5000 -W -m 8 -C 8
Stats: SAT revision 1.0.6_autoconf, 64 bit binary
Log: buildd @ x86-ubc-01 on Fri Mar 17 03:54:25 UTC 2017 from open source release
Log: 1 nodes, 4 cpus.
Log: Prefer plain malloc memory allocation.
Process Error: memalign returned 0
Process Error: failed to allocate memory
Process Error: Sat::Initialize() failed

Benutzeravatar
king-crash
Beiträge: 720
Registriert: 08.08.2006 12:07:56
Lizenz eigener Beiträge: MIT Lizenz

Re: OOM Killer triggert nicht bzw zu spät

Beitrag von king-crash » 28.09.2022 11:43:57

@hikaru:
Das ist mein Desktop System an dem ich alle paar Wochen mal eine VM starte. Wenn ich die dann aus welchem Grund auch immer vergesse und eine zweite starte und noch viele Tabs im Firefox aufhabe habe ich die Freezes schon beobachtet. Kommt wenn ich es quantifizieren müsste ca 4x im Jahr vor und ich bin erst jetzt darauf gekommen, das es am Speicherverbrauch liegen könnte (bin davon ausgegangen der OOM verhindert sowas).

Ja ich kann dafür sogar genau ein "knallhartes technisches Kriterium" definieren. Wenn weniger als 5% frei dann das Programm mit dem meisten RAM killen oder mit dem größten OOM Score.

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: OOM Killer triggert nicht bzw zu spät

Beitrag von hikaru » 28.09.2022 12:54:34

king-crash hat geschrieben: ↑ zum Beitrag ↑
28.09.2022 11:43:57
Ja ich kann dafür sogar genau ein "knallhartes technisches Kriterium" definieren. Wenn weniger als 5% frei dann das Programm mit dem meisten RAM killen oder mit dem größten OOM Score.
Das sollte sich scripten lassen. Alle nötigen Infos lassen sich z.B. aus einem top-Output grepen. Eine VBox-VM könnte man dann sogar kontrolliert per ACPI runterfahren und müsste sie nicht mal abschießen.
Aber eigentlich wäre ich zu faul, mir diese Arbeit zu machen. Wenn die VM eh nicht laufen soll, dann würde mich allein die Anzeige des RAM-Monitors daran erinnern, sie zu schließen.

Benutzeravatar
king-crash
Beiträge: 720
Registriert: 08.08.2006 12:07:56
Lizenz eigener Beiträge: MIT Lizenz

Re: OOM Killer triggert nicht bzw zu spät

Beitrag von king-crash » 28.09.2022 13:56:12

Wenn das Problem auftritt, ist es zu spät. Dann ist das System nicht mehr zu bedienen. Es kann sein, dass man Glück hat und nach > 30s der OOM anspringt oder sich ein Programm beendet. Ich habe allerdings auch schon nach mehreren Minuten den Reset Knopf drücken müssen. Ich würde befürchten, dass ein Script aufgrund der allgemeinen Trägheit eventuell nicht mehr Funktioniert (nichtmal die LEDs der Tastatur ändern sich noch). Eventuell probiere ich das aber aus.

Das Verhalten bei abgeschaltetem Overcommit verstehe ich auch nicht so ganz. Scheinbar kann ich den Speicher dann nur noch bis ca der Hälfte belegen. Ich habe das mittlerweile auch mit einem kleinen eingenen Programm getestet.

Daher die ganz konkreten Fragen:
Kennt jemand eine Möglichkeit den OOM Killer bei einem einstellbaren Speicherfüllstand anspringen zu lassen?
Warum wird das System überhaupt langsam, eigentlich bedeutet kein Speicher mehr doch einfach dass das nächste malloc fehlschlägt? Eine Nebenerscheinung des Overcommit?
Warum kann bei abgeschaltetem Overcommit nur noch grob der halbe Speicher verwendet werden?

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: OOM Killer triggert nicht bzw zu spät

Beitrag von Tintom » 28.09.2022 14:11:56

king-crash hat geschrieben: ↑ zum Beitrag ↑
28.09.2022 13:56:12
Ich würde befürchten, dass ein Script aufgrund der allgemeinen Trägheit eventuell nicht mehr Funktioniert (nichtmal die LEDs der Tastatur ändern sich noch).
Doch, es würde funktionieren. Abhängig natürlich davon wie hoch dein kritischer Wert ist. Ich hatte es bei mir bei 10% des verbliebenen RAM eingestellt und wurde zuverlässig gewarnt bzw. die Applikation wurde dann ohne mein Einwirken bei weiterem Speichermangel abgeschossen. Auf das killen der Applikation würde ich aber in deinem Fall verzichten, du kennst ja deine beiden Übeltäter und kannst sie manuell schließen.

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: OOM Killer triggert nicht bzw zu spät

Beitrag von hikaru » 28.09.2022 14:21:27

king-crash hat geschrieben: ↑ zum Beitrag ↑
28.09.2022 13:56:12
Wenn das Problem auftritt, ist es zu spät. Dann ist das System nicht mehr zu bedienen. Es kann sein, dass man Glück hat und nach > 30s der OOM anspringt oder sich ein Programm beendet. Ich habe allerdings auch schon nach mehreren Minuten den Reset Knopf drücken müssen. Ich würde befürchten, dass ein Script aufgrund der allgemeinen Trägheit eventuell nicht mehr Funktioniert (nichtmal die LEDs der Tastatur ändern sich noch). Eventuell probiere ich das aber aus.
Deshalb müsste das Script zu einem Zeitpunkt anspringen, bzw. die dadurch ausgelöste Aktion fertig werden, an dem noch alles funktioniert. Die von dir o.g. 95% erscheinen mir spontan passend, könnten aber auch schon zu spät sein, wenn du $dicke_VM sauber runterfahren willst, während $speicherhungriges_Programm gerade den RAM vollschaufelt.
king-crash hat geschrieben: ↑ zum Beitrag ↑
28.09.2022 13:56:12
Das Verhalten bei abgeschaltetem Overcommit verstehe ich auch nicht so ganz. Scheinbar kann ich den Speicher dann nur noch bis ca der Hälfte belegen. Ich habe das mittlerweile auch mit einem kleinen eingenen Programm getestet.
Das ist korrekt. 50% ist der Standardwert in /proc/sys/vm/overcommit_ratio , welcher aber nur relevant ist, wenn /proc/sys/vm/overcommit_memory "2" ist. Das sollte auch deine dritte Frage beantworten.
king-crash hat geschrieben: ↑ zum Beitrag ↑
28.09.2022 13:56:12
Warum wird das System überhaupt langsam, eigentlich bedeutet kein Speicher mehr doch einfach dass das nächste malloc fehlschlägt? Eine Nebenerscheinung des Overcommit?
Bei aktivem Overcommit schlägt so ein malloc über die Grenze des tatsächlich vorhandenen RAM nicht fehl. Gerade das ist ja die Idee des Overcommits, dass faule Programmierer sich nicht den Kopf darüber zerbrechen müssen, wie viel Speicher ihr Programm tatsächlich braucht. Im Grunde ist es eine Spekulation des Kernels darauf, dass es schon nicht so schlimm kommen wird, wie die Programme es ankündigen. Und meistens geht die Spekulation sogar auf, aber eben nicht immer.

Benutzeravatar
Blackbox
Beiträge: 4289
Registriert: 17.09.2008 17:01:20
Lizenz eigener Beiträge: GNU Free Documentation License

Re: OOM Killer triggert nicht bzw zu spät

Beitrag von Blackbox » 28.09.2022 14:40:00

king-crash hat geschrieben: ↑ zum Beitrag ↑
28.09.2022 09:09:40
Eigentlich würde ich im Sinne der Betriebssicherheit erwarten, dass der OOM Killer aufräumt bevor es zu derartigen Einschränkungen kommt.
Dieses Verhalten ist in der Vergangenheit einigen Verwendern auf die Füße gefallen.
king-crash hat geschrieben: ↑ zum Beitrag ↑
28.09.2022 09:09:40
Oder kennt jemand eine andere Lösung?
Weil mir dieses Verhalten von Debianoomd vor einer gewissen Vergangenheit auch bereits negativ auffiel, bin ich irgendwann auf Debianearlyoom ausgewichen.
Diese funktioniert recht zuverlässig, für meinen Geschmack manchmal zu früh.
Eigenbau PC: Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14

Freie Software unterstützen, Grundrechte stärken!

Benutzeravatar
Tintom
Moderator
Beiträge: 3029
Registriert: 14.04.2006 20:55:15
Wohnort: Göttingen

Re: OOM Killer triggert nicht bzw zu spät

Beitrag von Tintom » 28.09.2022 14:56:21

Blackbox hat geschrieben: ↑ zum Beitrag ↑
28.09.2022 14:40:00
Weil mir dieses Verhalten von Debianoomd vor einer gewissen Vergangenheit auch bereits negativ auffiel, bin ich irgendwann auf Debianearlyoom ausgewichen.
Diese funktioniert recht zuverlässig, für meinen Geschmack manchmal zu früh.
Danke! Ich wusste gar nicht, dass es schon etwas fertiges dafür gibt! Muss ich mir bei Gelegenheit mal anschauen.

Benutzeravatar
king-crash
Beiträge: 720
Registriert: 08.08.2006 12:07:56
Lizenz eigener Beiträge: MIT Lizenz

Re: OOM Killer triggert nicht bzw zu spät

Beitrag von king-crash » 28.09.2022 17:42:38

Dann hatte ich overcommit_ratio falsch verstanden. Ich ging davon aus, dass das der Wert des zusätzlich reservierbaren Speichers wäre. Ich habe jetzt overcommit_memory=2 und overcommit_ratio=90 und alles sieht wie ich es mir gewünscht habe aus. Versucht jetzt ein Programm mehr Speicher zu holen schlägt malloc einfach fehl und es gibt auch keine Hänger.

Besten Dank an alle.

Benutzeravatar
king-crash
Beiträge: 720
Registriert: 08.08.2006 12:07:56
Lizenz eigener Beiträge: MIT Lizenz

Re: OOM Killer triggert nicht bzw zu spät

Beitrag von king-crash » 30.09.2022 09:27:20

Da bei mir bei ausgeschaltetem Overcommit der Speicher schon ab in gnome-system-monitor angezeigten 80% Belegung ausgeht (Testprogramm NoPaste-Eintrag41804) würde ich gerne aus Interesse herausfinden, welche Programme ca 3GB anfordern aber nicht verwenden. Ist jemandem bekannt ob es hierzu eine Statistik gibt?

Edit: Ich habe das gerade nochmal Nachgeschaut. Wenn mein Testprogramm keinen Speicher mehr bekommt ist das hier die Ausgabe von free:
gesamt benutzt frei gemns. Puffer/Cache verfügbar
Speicher: 16375524 11883796 180732 30100 4310996 4168724
Swap: 0 0 0
4G sind ja doch kein Pappenstiel.

Antworten