Merls Blog

Dieses und Jenes
Subscribe

Genug Swap und trotzdem OOM-Killer

Juni 07, 2011 By: Merl Category: Linux, Server

Ich hatte ja vor kurzem Swapspace1 eingerichtet. Damit dürfte, so der Gedanke, der Server nicht mehr wegen Speichermangels abschmieren. Ging nen Monat gut, und dann war er wieder weg und der gute alte bekannte oom-killer hatte seine Spuren im syslog hinterlassen. Also zurück ans Reissbrett.. oder doch nicht?

Nach etwas weiteren Googlesuchen stolperte ich über einen Artikel2 von Henrik Skupin3 in dem er sich ebenfalls über die sinnbefreiten Defaults die es teilweise unter Linux gibt auslässt.

Anlass für seinen Artikel war genau mein Problem, trotzdem ausreichend Swap vorhanden ist, kommt der oom-killer und schießt Prozesse ab. Manchmal läuft der Server für Wochen ohne Probleme, dann stirbt er wieder mehrmals täglich.

Henrik wiederrum verweist auf ein Dokument „The Linux Kernel“4 von Andries Brouwer. Dort ist insbesondere das Kapitel 9.6 „Overcommit and OOM“5 interessant.

Kurz gesagt: Anders als andere Unixe, gibt Linux gerne jedem Programm soviel Speicher wie es verlangt, in der Hoffnung, dass es mehr verlangt als es braucht. Brauchen die Programme dann aber doch mehr als vorhanden ist, kommt unser Freund der oom-killer und versucht möglichst nicht vitale Prozesse abzuschießen. Die Betonung liegt auf versucht, irgendwann erwischts den falschen Prozess. Wiedermal ein toller default!

Mit Kernel 2.1.27 ist den Entwicklern dann auch aufgefallen, dass das Quark ist und sie haben eine Option geschaffen das verhalten des Kernels zu beeinflussen. Ab da gab es die Möglichkeit 0 oder 1 in die Datei /proc/sys/vm/overcommit_memory zu schreiben. Die Funktion der beiden Variablen ist aber auch wieder sehr sinnbefreit:

  • 0 – default, „kein overcommit“, in Anführungszeichen weil es für den Kernel nur heist „denk ein bisschen nach bevor dus machst“
  • 1 – immer overcommit, erklärt sich denke ich selbst

Erst mit Kernel 2.5.30 kam endlich eine dritte Variable hinzu:

  • 2 – overcommit bis maximal Swap + /proc/sys/vm/overcommit_ratio % des RAM

Damit ist es Möglich, den Kernel zu einer sinnvollen Speicherverwaltung zu überreden. Mit den im Dokument vorgeschlagenen Werten bekommen Programme immenroch genug Speicher reserviert, der Swap wächst weiterhin bei bedarf und das wichtigste: Es werden keine zufälligen Prozesse mehr abgeschossen. Stattdessen stirbt der Prozess der zuviel Arbeitsspeicher reservieren will weil er den nicht bekommt (oder ist sauber programmiert und reagiert entsprechend).

Die Lösung ist also folgende:

In der Datei /etc/sysctl.conf werden folgende Werte eingetragen:

vm.overcommit_memory = 2
vm.overcommit_ratio = 80

Das wars auch schon. Seit ich diese Änderung eingetragen habe ist der oom-killer nicht wieder aufgetaucht.

Auch ein test mit den demoX.c Programmen aus dem Linux Kernel Dokument hat genau das dort beschriebene Bild gezeigt. Mit der Änderung führt das ausführen der Programme nie zum Systemcrash, lediglich die Programme bekomme nirgendwann keinen Speicher mehr und beenden sich selbst.

Leave a Reply

*