burn a church
Zucht und Ordnung from hell

Linux hat ein recht eigenwilliges, wie ansatzweise intelligentes Swapverhalten. Wie jedes (moderne) Betriebssystem, benötigt diese eben auch Linux, um Daten aus dem Arbeitsspeicher auszlagern, wenn der zur Verfügung stehende Arbeitsspeicher nicht mehr reicht. Linux versucht dabei den Arbeitsspeicher möglichst intelligent zu verwalten und eben nicht zwingend, den gesamten Arbeitsspeicher für Programme zur Verfügung zu stellen.

Freier Speicher? Gecachter Speicher?

Dem interessierten Linuxbenutzer fällt dies spätestens auf, wenn er das Programm free(1) benutzt. Dann sieht man ungefähr so etwas:

bibo:/# free -om
total       used       free     shared    buffers     cached
Mem:          2027       1957         69          0         28       1188
Swap:         2384         18       2366

Nun kommt man recht schnell dahinter, dass diese Maschine 2 GB Arbeitsspeicher hat - davon 1,9 benutzt und 69 MB frei. Zusätzlich gibt es offenbar eine (oder mehrere) Swappartition(-en) zu 2,3 GB, wovon 18 MB benutzt sind. Fragen werfen allerdings die 1,18 GB auf, die der Kernel unter “cached” verzeichnet. Genau dieser Wert ist der entscheidende. Tatsächlich sind nämlich eben nicht 1,9 GB des Arbeitsspeichers in Benutzung, sondern über ein Gigabyte weniger. Den restlichen Speicher belegt Linux mit zwischengespeicherten Dateien.

Wann immer das System oder der Benutzer eine Datei öffnet, kann der Kernel die Entscheidung treffen, diese Datei in den Arbeitsspeicher zu laden. Dies beschleunigt den Lesevorgang ungemein - wenn nun eine Datei oft gelesen werden soll, ist das ein sehr gewichtiges Argument. Im Gegenzug, steht aber eben auch weniger Platz für den belegten Speicher laufender Programme zur Verfügung. Es ist also ein Balanceakt für den Kernel, zu entscheiden, welche Strategie die Klügere ist und ob in Zukunft eher gecachter Platz frei gemacht werden soll oder nicht.

Das ist wesentlich wichtiger, als es scheint, denn ist kein Platz für die Anwendungen im Hauptspeicher mehr vorhanden, muss dieser in der Swapdatei, der Festplatte, gefunden werden - was im Vergleich zum Arbeitsspeicher extrem langsam ist. Für einen hochbeanspruchten Server, ist dies für gewöhnlich der Todesstoß. Der Administrator kann über vmstat(8) jederzeit überprüfen, ob der Kernel gegenwärtig Speicherseiten in die Swapdatei auslagert.

Das Swapverhalten beeinflussen

Wann immer eine Anfrage von einem Programm kommt, Speicherplatz anzufordern, muss der Kernel entscheiden, welche Schlüsse er daraus zieht. Mit Kernel 2.6 gibt es für den Administrator eine undokumentierte Möglichkeit, einen Faktor zu definieren, der dieses Verhalten maßgeblich beeinflusst.

Die Wahrscheinlichkeit, dass der Kernel dazu neigt, Programme in die Swapdatei auszulagern ist in mm/vmscan.c im Kernelquellcode wie folgt definiert:

swap_tendency = mapped_ratio / 2 + distress + vm_swappiness;

Dabei gibt es also offensichtlich drei Parameter:

• Der “distress” Parameter, ist eine Variable, mit der der Kernel einschätzt, wie groß die Probleme sind, Speicher freizugeben. Mit zunehmender Systemauslastung wird dies natürlich schwieriger. Zu Beginn liegt dieser Wert bei 0 und kann auf bis zu 100 ansteigen.
• Der “mapped_ratio” Parameter ist ein angenäherter Wert, der Auskunft darüber gibt, wieviel Prozent des Systemspeichers adressiert, also benutzt ist.
• Der “vm_swappiness” Parameter ist standardmäßig auf 60 gesetzt. Dieser Wert kann allerdings durch den Administrator beeinflusst werden. Damit kann maßgeblich auf die Entscheidungsfindung der Kernels eingegriffen werden. Zugänglich ist dieser Wert über das virtuelle Proc-Dateisystem auf /proc/sys/vm/swappiness.

Ist das Ergebnis, die “swap_tendency” unter 100, wird der Kernel auf jeden Fall versuchen, gecachten Speicher freizugeben und somit Swapping unterbinden. Erst wenn dieser Wert diese Schwelle überschreitet, überlegt sich der Kernel ernsthaft den Cachespeicher beizubehalten und Programmspeicher auszulagern.
Angesichts des Standardwertes für “vm_swappiness” (60) bedeutet dies, dass der Kernel erst bei einer Speicherauslastung von über 80% überhaupt in Erwägung zieht, Programme auszulagern (zumindest solange man den nicht pauschalisierbaren “distress“-Faktor außer Acht lässt). Umgekehrt kann man den Kernel so auch einfach daran hindern, Programme in die Swapdatei auszulagern, indem man den Wert auf 0 setzt. Getan wird dies, ganz einfach über:

bibo:/# echo 0 > /proc/sys/vm/swappiness

Für einen Applikationsserver ist dies durchaus mal eine Überlegung wert, damit zu experimentieren. Dieser hat in der Regel nämlich (sehr) viele Prozesse bei relativ wenig Overhead durch Dateien. Allerdings ist Sinn und Unsinn einer Manipulation dieses Faktors stark umstritten, auch und insbesondere auf der Linux-Kernel-Mailinglist. Hat man allerdings einen zufriedenstellenden Wert gefunden, kann der auch festgeschrieben werden, “/proc”-Parameter verlieren nämlich durch einen Reboot ihre Gültigkeit. Soll der dauerhaft gespeichert werden, muss /etc/sysctl.conf wie folgt editiert werden:

/etc/sysctl.conf:

vm.swappiness =  <0 .. 100>

Kategorien

Verwandte Artikel

• SYN-Flood kurz erklärt (10)
• SQL-Injection kurz erklärt (6)
• Ressourcenverwaltung mit Xen (0)
• Lighttpd - Web 2.0 und Unmut (5)
• ksshmenu - Ein grafischer SSH-Manager für KDE (25)