Kernelverhalten bei out-of-memory

[dino]

Hallo,

ich habe eine Problem aus dem sich eine Verständnisfrage ergibt: Was tut der Kernel wenn kein RAM mehr zur verfügung steht? Nun, swap'en - aber wenn es keinen swap gibt? So weit ich das in Erfahrung gebracht habe, scheint er dann dem nächsten Programm, das mehr Speicher verlangt einen Fehler zurückzugeben und dieses - je nach dem wie es damit umgeht - stirbt vermutlich.

So weit die Theorie - in der Praxis sieht es so aus, das auf einem System ohne swap, das gesamte system einfriert (naja, fast, es sehr sehr langsam reagiert), wenn der ram eng wird und die festplatte nicht mehr aufhört zu arbeiten - also Quizfrage: was tut das System?

Die einzige erklärung die mir gerade logisch erscheint ist, dass die meisten Programme doch nicht sterben wenn sie kein ram mehr bekommen und lagern selbst daten auf die festplatte aus.

[Spasswolf]

Dann randaliert der oom-killer.

[dino]

Genau den vermisse ich
Der oom-killer sollte doch einen (oder mehrere) processe killen - wozu braucht er da die festplatte?

von http://linux-mm.org/OOM_Killer:

So the ideal candidate for liquidation is a recently started, non privileged process which together with it's children uses lots of memory, has been nice'd, and does no raw I/O. Something like a nohup'd parallel kernel build (which is not a bad choice since all results are saved to disk and very little work is lost when a 'make' is terminated)

Hatte jetzt ca. 3 mal den fall dass ein prozess fast meinen gesamten speicher "gefressen" hat und das system (laptop, 2x1.6 ghz, 64bit system mit 4gb ram) nicht mehr benützbar war (bild mehr oder weniger eingefroren, tasten, auch strg+alt+f1 werden ignoriert) - auch nach 10min änderte sich nichts, eigentlich hätte er ja mein amok-laufendes make abschiessen sollen und alles wäre wieder gut gewesehn, oder? (und das sollte keine 10min dauern?)

[cosmac]

hi,

sowas hab' ich auf Rechnern ohne Swap auch schon erlebt. Meine Theorie: der Kernel gibt Seiten frei, die aus einer Datei stammen und nicht verändert wurden, also vor allem Programm-Code. Wenn das Programm einen Befehl aus der betroffenen Seite ausführen will, wird sie wieder aus der Datei geholt und dafür eine andere Seite aufgegeben. Unter den Umständen wartet das System die meiste Zeit auf die Platte, kann aber in der Zwischenzeit keinen anderen Prozess laufen lassen.

[storm]

Der oom-killer sollte doch einen (oder mehrere) processe killen - wozu braucht er da die festplatte?

Wie kommst du auf die Festplatte? Der oom-killer hat damit nichts zu tun. Falls du den Abschnitt in der zitierten Passage meinst, dann ist damit ja das make gemeint, das immer nur den aktuellen code übersetzt und das Objekt wegschreibt. Und hast du mal im syslog nachgeschaut, ob der killer nicht vielleicht doch angesprungen ist (und nur nicht hinterher gekommen ist)?

Hatte jetzt ca. 3 mal den fall dass ein prozess fast meinen gesamten speicher "gefressen" hat und das system (laptop, 2x1.6 ghz, 64bit system mit 4gb ram) nicht mehr benützbar war (bild mehr oder weniger eingefroren, tasten, auch strg+alt+f1 werden ignoriert) - auch nach 10min änderte sich nichts, eigentlich hätte er ja mein amok-laufendes make abschiessen sollen und alles wäre wieder gut gewesehn, oder? (und das sollte keine 10min dauern?)

Erstmal ein Kommentar zu einem passenden Artikel auf lwn.net:

The OOM killer is just a less drastic form of panic. When it runs, the system is broken. There are even cases where a panic would be better.

Wie hast du denn dein make gestartet (und welchen Kernel setzt du denn ein)? Cosmac hat glaub ich schon einen guten Hinweis gebracht, unter Umständen schafft der das gar nicht (andere Funktionen des kernels brauchen länger oder werden viel häufiger aufgerufen).

ciao, storm

[Spasswolf]

Der oom Killer killt aber nicht unbedingt den Verursacher sonder rechnet erstmal einen badness Wert für jeden Prozess aus basierend auf dessen Speichernutzung, Cpuzeit, Anzahl der Kindprozesse etc, um dann den Prozess mit dem höchsten Wert zu killen. Diesen Wert für "ausgeswappte" Prozesse zu berechnen führt eventuell zu der erhöhten Festplattenaktivität.

[dino]

Danke für eure antworten!

Der oom-killer sollte doch einen (oder mehrere) processe killen - wozu braucht er da die festplatte?

Wie kommst du auf die Festplatte? Der oom-killer hat damit nichts zu tun. [...]

Nun, genau das ist der Punkt - der theorie nach, sehe ich kein zusammenhang mit der festplatte, in der Praxis jedoch schon: Ich höre sie leise und die ladelampe leuchtet durchgängig

Wie hast du denn dein make gestartet (und welchen Kernel setzt du denn ein)? Cosmac hat glaub ich schon einen guten Hinweis gebracht, unter Umständen schafft der das gar nicht (andere Funktionen des kernels brauchen länger oder werden viel häufiger aufgerufen).

ciao, storm

Ich hatte die situation dass sich das gesamte system weghängt nun drei mal, zweimal beim compilieren des kernels mit "make -j 2" ... ohne -j2 braucht er kaum ram, mit -j 2 über 3gb, das ist aber ein aderer bug um den es mir gar nicht geht - mich interessiert mehr, warum danach das system komplett steht. Der speicherverbrau ging innerhalb von ca 3. sec von ~100mb auf > 3gb

Die dritte situation war ein kleines aber fieses skript das nich auf speicher-effektivität getrimmt war und so etwa 3gb ram belegte, was mehr war als ich frei hatte. Der speicherverbrauch hier stieg eher lagsam und konstant und als kaum noch etwas frei war bewegt sich nichts mehr. (das skript versuchte zu dem zeitpunkt vermutlich etwas festplatten IO, aber nicht sonderlich viel)

Diesen Wert für "ausgeswappte" Prozesse zu berechnen führt eventuell zu der erhöhten Festplattenaktivität.

Das hätte ich noch verstanden, doch hat das system 0 swap

sowas hab' ich auf Rechnern ohne Swap auch schon erlebt. Meine Theorie: der Kernel gibt Seiten frei, die aus einer Datei stammen und nicht verändert wurden, also vor allem Programm-Code.

Interessante theorie. Mal schauen ob ich da was zu finde in der richtung, doch der oom-killer sollte doch einen ganzen prozess einfach töten und nicht einzelne seiten freigeben, oder?

Eine weitere theorie, die mir gerade kam:
Der oom-killer kam noch gar nicht zum einsatz, sondern der speicher ist nur fast voll und kein/kaum platz mehr für cache und buffer, dadurch der höhere festplatten zugriff, was das system dann letztlich verlangsamt.

[cosmac]

sowas hab' ich auf Rechnern ohne Swap auch schon erlebt. Meine Theorie: der Kernel gibt Seiten frei, die aus einer Datei stammen und nicht verändert wurden, also vor allem Programm-Code.

Interessante theorie. Mal schauen ob ich da was zu finde in der richtung, doch der oom-killer sollte doch einen ganzen prozess einfach töten und nicht einzelne seiten freigeben, oder?

ja, aber solange der Kernel noch einzelne Seiten freigeben kann, sollte der oom-killer garnicht zum Einsatz kommen. Das sind ja zwei ganz verschiedene Mechanismen. Wobei es natürlich vom Einsatz abhängt, was das kleinere Übel ist, ein extrem langsames System oder abgeschossene Prozesse.

Eine weitere theorie, die mir gerade kam:
Der oom-killer kam noch gar nicht zum einsatz, sondern der speicher ist nur fast voll und kein/kaum platz mehr für cache und buffer, dadurch der höhere festplatten zugriff, was das system dann letztlich verlangsamt.

Das kommt auf jeden Fall erschwerend hinzu.

[storm]

Nun, genau das ist der Punkt - der theorie nach, sehe ich kein zusammenhang mit der festplatte, in der Praxis jedoch schon: Ich höre sie leise und die ladelampe leuchtet durchgängig ;)

Na beim make im Hintergrund wär das erklärbar, bei anderen Porzessen müsstest du halt kucken, was die schreiben wollen. Falls das mit make -j 2 reproduzierbar ist, könntest du gut ein terminal mit top laufen lassen (und das delay sehr niedrig ansetzen).

Ich hatte die situation dass sich das gesamte system weghängt nun drei mal, zweimal beim compilieren des kernels mit "make -j 2" ... ohne -j2 braucht er kaum ram, mit -j 2 über 3gb, das ist aber ein aderer bug um den es mir gar nicht geht - mich interessiert mehr, warum danach das system komplett steht. Der speicherverbrau ging innerhalb von ca 3. sec von ~100mb auf > 3gb

Ehm, wenn du sicher weisst, das da ein bug vorhanden ist, solltest du dich erst um den kümmern. Nur zur Erinnerung: make -j 2 bedeutet das make immer versucht 2 Kommandos gleichzeitig auszuführen, aber ohne die 2 gibt es kein limit und make baut erst _rekursiv_ den kompletten Stapel an Befehlen auf, bevor irgendein Kommando tatsächlich ausgeführt wird. Und deine Fehlerbeschreibung "riecht" auch leicht nach so etwas.

Ehm, nochmal: welcher Kernel?

ciao, storm

[dino]

Ehm, nochmal: welcher Kernel?

Das problem tritt sowohl bei 2.6.26 auf als auch bei dem gebauten 2.6.27. Der bug mit make das zu viel ram frisst ist eine sache, dass das system deswegen "einfriert" eine andere. Da das "einfrieren" auch in anderen situationen vorkommt bei denen wenig/kein ram mehr zur verfügung stehen, ist mir das gerade wichtiger

ich denke mal das es eine kombination aus "try_to_free_pages" und der tatsache dass kein/kaum noch cache da ist, die ursache dafür ist, dass system zum (pseudo)freez.

Am liebsten wäre mir, wenn der oom-killer früher eingreift, da würden weniger daten verlorgen gehen, denn ich muss das system nicht neubooten und alles ist weg. Vllt finde ich eine möglichkeit (kernel config, o.ae.).

[storm]

Am liebsten wäre mir, wenn der oom-killer früher eingreift, da würden weniger daten verlorgen gehen, denn ich muss das system nicht neubooten und alles ist weg. Vllt finde ich eine möglichkeit (kernel config, o.ae.).

Eine Möglichkeit wäre mal vm.overcommit=2 (no overcommit) auszuprobieren. Die default-Einstellung ist da 0 (mehr Speicher als vorhanden zu allozieren ist möglich). Machst du im xterm als root so:

Code: Alles auswählen

sysctl -w vm.overcommit_memory=2
# und ratio vielleicht auch gleich setzen
sysctl -w vm.overcommit_ratio=100

Und vielleicht mal in der kernel-doku nachlesen: ~/Documentation/vm/overcommit-accounting.

ciao, storm