Nach etwas weiteren Googlesuchen stolperte ich über einen Artikel² von Henrik Skupin³ 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”⁴ von Andries Brouwer. Dort ist insbesondere das Kapitel 9.6 “Overcommit and OOM”⁵ 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.

Im Verdacht habe ich Momentan Apache in Verbindung mit zu wenig Swap-Space. Die Swap Partition ist 1GB groß, ebenso wie der RAM. Ich habe schon vor längerem beobachtet, dass der Swap offensichtlich voll läuft kurz bevor der Server nicht mehr antwortet. Ein Script das von Cron aufgerufen wird und mir verschiedene statistische Daten per Mail liefert wenn es rechtzeitig den ausgehenden Speicher bemerkt, zeigt deutlich eine unheimliche Anzahl von Apache Prozessen.

Blöd nur, dass man in einen gemieteten Server nur sehr schlecht neue Hardware bekommt und bei einer nicht lvm-Installation das Ändern der Plattengrößen, nun sagen wir, problematisch ist. Nach dem letzten Absturz war mir das dann doch zu viel und ich war bereits soweit das Risiko in kauf zu nehmen. Dank Onkel Google habe ich dann aber ein nützliches Tool gefunden, dass genau solche Situation wie sie sich mir stellen abzupuffern hilft: Swapspace¹.

Swapspace ist ein Daemon, der den Speicher überwacht und wenn dieser droht auszugehen dynamisch neue Swap-Dateien erstellt und wieder löscht. Das ganze macht er dann noch dazu sehr intelligent, so dass keine überflüssigen Swap-Dateien herumfliegen.

Da der Server im Regelfall den Swap nicht braucht kann ich zum jetzigen Zeitpunkt noch nicht sagen, ob Swapspace die Probleme löst. Wenn ich mit meinem Verdacht recht habe, gehe ich aber fest davon aus.

Jedenfalls ist gestern Abend mein Server kaum erreichbar gewesen, nach einigen Neustarts kam ich dann erstens darauf, dass sämtliche Services neben IPv4 Abfragen auch IPv6 abfragen versucht haben, was auf einem nur mit IPv4 angebundenen Server wenig Sinn macht, nur zu unnötigen Timeouts führt und die Logs mit Fehlermeldungen voll haut.

Entsprechend habe ich dann zuerst mal Bind9, Apache und Postfix auf reinen IPv4 Betrieb umgestellt:

Bind9:

in der Datei /etc/defaults/bind9

OPTIONS="-u bind"
# Set RESOLVCONF=no to not run resolvconf
RESOLVCONF=yes

wird zu:

OPTIONS="-4 -u bind"
# Set RESOLVCONF=no to not run resolvconf
RESOLVCONF=yes

Apache:

in allen Dateien unter /etc/apache2/sites-available/

Listen 80 #Mischbetrieb

wird geändert in die Form

Listen 0.0.0.0:80
Listen 192.170.2.1:80

Dabei natürlich die richtige IP dabei eingeben.

Dabei hab ich auch gleich mal den von Apache jedesmal beim Start angemahnten mischbetrieb von Wildcard und festen Virtualhosts aufgelöst, sprich alle * durch IP ersetzt.

Postfix:

In der /etc/postfix/main.cf

inet_protocol = ipv4

Nachdem ich das alles umgestellt hatte, waren zumindest die Logs mal sicher vor IPv6 Fehlermeldungen und es gab weniger Timeouts. Die CPU-Load ging aber immernoch auf 100%. Dabei fiel mir auf, dass ständig Spamassasin und clamscan liefen. Also mal ein wenig in den Virtualmineinstellungen geschmöckert.

Und siehe da: unter Email Messages > Spam and Virus scanning findet sich die Option Virus scanning programm, die per default auf Standalone scanner (clamscan) steht. Liest man sich den Hilfetext durch, erfährt man, dass der immer funktioniert. Nebenher läuft aber auch per default noch der clamdscan als Prozess, der natürlich nix zu tun hat und eigentlich schneller wäre.

Also Scanner auf clamdscan umgestellt, oh wunder, keine clamscan Prozesse mehr. Und die CPU-Load ist auch wieder in nem normalen bereich und hat ne ordentliche idle-time.

Das werd ich jetzt mal n paar Tage beobachten und mir dann überlegen, ob ich den Scanner laufen lasse oder ganz abschalte um noch etwas mehr Leistung freizugeben. Im Moment siehts ganz gut aus, der Deamon ist doch erheblich performanter als für jeden Scan n eigenen Prozess zu starten.

Plugin Update:

Wärend dem Schreiben dieses Artikels habe ich das Plugin für den Syntaxhighlighter auf SyntaxHighlighter ComPress von Andre Gärtner geändert.
Das hat unter anderem den Vorteil, dass es die benötigten JavaScript Dateien dynamisch einbindet und damit weniger Ladezeit benötigt. Außerdem nutzt es das aktuelle SyntaxHighlighter JS, das für Copy&Paste kein Flash mehr benötigt.

Links:

• Bind9 IPv4 only
• Apache IPv6 Considarations
• Virtualmin
• SyntaxHighlighter ComPress

httpd_spezial:

Directory "/var/www/web1/html">
Options +SymLinksIfOwnerMatch
php_admin_value safe_mode off
php_admin_flag safe_mode off
php_admin_value open_basedir none
</Directory>