Swap unter Linux, ein paar Notizen

Da ich zum Teil immer wieder darauf stoße und gelegentlich danach gefragt werde, hier mal mein gesammeltes Wissen über Swap unter Linux. Wie immer bei sowas gilt: YMMV.

Was ist der Sinn?

Hin und wieder begegnen mir Mißverständnisse darüber was Swap eigentlich ist: es ist zusätzlicher Arbeitsspeicher, man spricht auch von Virtuellem Speicher (wobei der Begriff eigentlich nicht korrekt ist), in Windows-Sprech würde man es Auslagerungsdatei nennen.

Für Swap gibt es zwei Anwendungsfälle:

1. ) Wenn dem Kernel mal akut der freie RAM zur Neige geht weil zu viele Prozesse laufen, dann müßte er normalerweise irgendwann anfangen Prozesse abzuschießen. Das ist dann für den Prozess und vor allem die von ihm verwalteten Daten mit hoher Wahrscheinlichkeit unangenehm. Hat der Kernel aber Swap zur Verfügung, kann er erstmal dorthin Pages aus dem RAM auslagern. Der Nachteil ist, daß das System ab diesem Moment langsam wird, denn die Zugriffszeiten selbst schneller Festplatten können nicht mit denen von echtem RAM konkurrieren. Der Server der also ohnehin schon in den Seilen hängt, beginnt dann in die Knie zu gehen, aber immerhin ist er noch nicht K.O. Man erreicht also, daß der Kernel noch ein paar Minuten länger durchhält bevor er Prozesse abschießen muß, damit man z.B. als Admin vielleicht noch eine Chance hat sich einzuloggen, nachzuschauen was los ist und die Ursache zu bekämpfen.

2.) Selbst bei gut geschriebenen Programmen ist es kaum zu vermeiden, daß sie mehr Speicher belegen als pro Benutzung eigentlich gebraucht wird (außer vielleicht bei Programmen die nur einzelne Kleinstaufgaben erledigen). Das hängt auch oft davon ab, welches Nutzerverhalten auftritt: wer etwa ein Videoschnittprogramm benutzt um nur eine Tonspur zu schneiden, braucht die Videoroutinen nicht, wer Evolution offen hat und nur IMAP nutzt, braucht die POP3-Routinen nicht, wer LibreOffce nutzt um Briefe zu schreiben, braucht keine Tabellenkalkulations-Routinen usw., wer Linux ohne X11 auf einem Server betreibt, braucht die ganzen Routinen für die graphische Benutzeroberfläche nicht und wer ein Virtuelles System laufen läßt, braucht in diesem nicht in der inittab sechs Konsolen mit mingetty aufzumachen, weil durch die Virtualisierung eh nur eine einzelne angesprochen wird. Nun kann der Kernel anhand der Speicherzugriffe eines Programmes erkennen welche Teile des ihm zugewiesenen Speichers ein Programm nicht braucht und diese dann in den Swap bewegen. Zu einem gewissen Grad kann der Kernel das manchmal sogar antizipieren. Bei Programmen die lange inaktiv sind, kann der Kernel sie auch komplett für die Dauer ihrer Inaktivität in den Swap bewegen, wenn er sie von dort zurück holt ist das immer noch schneller als wenn das Programm neu gestartet würde, da es im Swap ja bereit so vorliegt daß es 1:1 in den RAM kopiert werden kann (davon profitieren am stärksten Programme in Skriptsprachen, die nicht nochmal durch den Interpreter oder Just-in-time-compiler müssen — außer bei Java, das diesen Mechanismus anscheinend aushebelt).

Linux-Distributionen bevorzugen (anders als Windows und MacOS X) beim Swap (wie die meisten unixoiden Betriebssysteme) die Verwendung von Partitionen statt von Dateien. Wobei dies mittlerweile eher aus Tradition geschieht denn aus technischer Notwendigkeit. Man kann durchaus auch Swapfiles benutzen (siehe unten). In jedem Fall wird die Größe des Swap unter Linux vorher festgelegt, Linux kann nicht (wie z.B. Windows oder MacOS X) dynamisch weitere leere Bereiche auf der Festplatte als Swap appropriieren, wenn auch der Swap zur Neige geht. (Das ist eine gute Sache, sonst hat man irgendwann das Problem, daß nicht nur der Swap voll ist, sondern auch das Dateisystem und dann geht’s wirklich bergab.)

Größe

Es ist erstaunlich wie lange sich alte Faustregeln wie „der Swap sollte vier mal so groß sein wie der RAM“ halten, sie sind einfach nicht tot zu kriegen. Zunächst einmal: Ein System mit i386er Architektur kann nicht mehr als 4 GiB Speicher adressieren, egal ob es sich um RAM oder Swap handelt. Einem i386er-System mit 2 GiB RAM ganze 8 GiB Swap zu verpassen, ist weitgehend nutzlos.

Bei Systemen mit x86_64er Architektur stellt sich die Sache deutlich anders da, hier könnte man komplette Festplatten als Swap verwenden. Adressierbar sind mit den meisten Speicherkontrollern 256 TiB (Tebibyte, entsprechend einem 48 Bit Adressraum), da der Speicherkontroller mit dem Swap jedoch nichts zu tun hat, könnten dank 64-Bit-Adressraum der Architektur theoretisch sogar 16 EiB (Exibyte) genutzt werden — also weit mehr als selbst große Festplatten oder RAID-Systeme heutzutage bieten (wobei soweit ich weiß noch kein gängiges Betriebssystem wirklich bereit ist die vollen 64 Bit zu nutzen). Das alles ist jedoch eine rein theoretische Geschichte, denn niemand will, daß sein System Gibibyte-weise Swap rausschreibt. Auch hier sind 4 GiB mehr als genug, meiner Erfahrung nach genügen meist sogar 2 GiB, wenn mehr als 4 GiB RAM vorhanden sind.

Partition oder Datei?

Ja Gretchen, wie halten Sie es denn mit dem Swap? Es ist letztlich eine Glaubensfrage. Viele altgediente Linux-User bestehen auf Swap-Partitionen und lehnen Swapfiles kategorisch ab. Früher ging der Linux-Kernel mit mit Swapfiles deutlich ineffizienter um als mit Partitionen, dies ist aber schon lange nicht mehr der Fall.

Das verbleibende Hauptargument für eine Swap-Partition ist, daß sie kontinuierlich ist und somit nicht fragmentieren kann. Nun ist Fragmentierung bei Linux nicht so schlimm und große Dateien sind in Dateisystemen die in Extends strukturiert sind immer ein bißchen fragmentiert. Starke Fragmentierung kann aber auch unter Linux negative Auswirkungen auf die Performance haben, wovon jeder MySQL-Admin der InnoDB einsetzt ein Liedchen singen kann. (Dateien zu defragmentieren ist bei Linux übrigens ziemlich knifflig, da etwa für ext2, ext3, ext4 und ReiserFS kaum Defragmentierungs-Tools existieren und einem in Foren und auf Mailinglisten auch eher ein wenig hilfreiches, kategorisches „Linux braucht nicht zu defragmentieren“ entgegenschallt — auch wenn das natürlich nicht immer stimmt.)

Geringe Fragmentierung eines Swapfiles wäre also wie gesagt nicht schlimm und das gute an einem Swapfile mit seiner fixen Größe ist, daß er nicht nachträglich fragmentieren kann, denn er wird ja nicht größer. Hier muß man jedoch aufpassen: Bei Dateisystemen die Copy-on-Write verwenden (BtrFS, ZFS, kurz: die Zukunft) können Swapfiles wieder fragmentieren. Bei diesen Dateisystemen kommen außerdem noch Checksummen zum Einsatz, um Silent Data Corruption (etwa durch ein umgefallenes Bit auf einer Festplatte) zu erkennen und zu behandeln. Auf so einem Dateisystem sind Swapfiles nicht sinnvoll.

Also wer ein Dateisystem ohne Copy-on-Write und extensives Checksumming verwendet, kann sich die Mühe beim Partitionieren sparen:

# dd if=/dev/zero of=/swapfile0 bs=1k count=2097152
# mkswap /swapfile0
# swapon /swapfile0
# echo "/swapfile0 swap swap defaults 0 0" >> /etc/fstab

Die Zahl die man bei dd hinter count= eintragen muß richtet sich danach, wie groß die Datei sein soll. Hier wurde 2048 * 1024 (1k) gerechnet, also 2 GiB.

Swappiness

In den meisten Fällen swappt Linux nicht so rasch wie einige andere Betriebssysteme. MacOS X z.B. swappt meist schon beim Booten, allerdings weniger aus Mangel an RAM, sondern vielmehr weil XNU (der MacOS X Kernel) versucht präemptiv zu swappen, also allozierten Speicher der mit hoher Wahrscheinlichkeit nicht oder nur selten genutzt werden wird frühzeitig in den Swap zu bewegen und so den RAM länger frei zu halten. Linux kann das auch, ist da aber deutlich zurückhaltender.

Linux hat allerdings eine Neigung seinen RAM schnell zu füllen und das liegt daran, daß Linux bestimmte Daten die es immer wieder braucht oder von denen es erwartet sie zu brauchen schonmal im RAM zwischenspeichert. In der Ausgabe von free taucht dies dann als +/- buffers/cache auf. Bevor Linux anfängt zu swappen wird es oft diesen Speicher erstmal wieder frei schaufeln (sofern dies sinnvoll ist).

Wie Swap-freudig Linux ist läßt sich justieren und das ist sogar recht wichtig, wenn man Linux auf Servern einsetzen will. Die meisten Linux-Distributionen sind nämlich für den Desktop-Einsatz optimiert und das heißt, daß die Swap-Freudigkeit (swappiness) des Kernels dort relativ hoch ist. An einem Desktop sitzt ja auch ein Benutzer der bemerkt wenn der Rechner langsamer wird und sich dann denken könnte, daß er vielleicht zu viele Programme offen hat und dann anfangen könnte, welche zu beenden. An einem Server sitzt aber meist niemand, also kann es sinnvoll sein hier die Swappiness runter zu drehen.

Typische Default-Werte für die Swappiness sind heutzutage 60 oder 70. Die Skala reicht von 0 (swappe nur wenn es nicht anders geht) bis 100 (swappe beim geringsten Anlaß). Was man hier bevorzugt, muß man selbst entscheiden. Es kann durchaus eine gute Idee sein, hier mit hohen Werten zu arbeiten, um im Normalbetrieb ungenutze Speicherseiten großer Programme aus dem RAM zu bekommen. Auf einem Server kann Swap nützlich sein, oder gänzlich unnütz. Je nachdem kann man den Wert hoch oder niedrig einstellen. Ich persönlich bevorzuge auf Laptops (dort nehme ich immer langsame, stromsparende Festplatten) und Servern Werte von 30 bis 0 (auf Servern schalte ich immer alles ab was nicht gebraucht wird, das spart oft schon genug RAM). Es kann aber auch auf Servern sinnvoll sein hohe Werte zu verwenden, wenn man viele schlafende Prozesse hat, die die meiste Zeit nur RAM belegen.

Um die Swappiness einzustellen muß man bei den meisten Distributionen die /etc/sysctl.conf editieren und dort z.B. folgendes eintragen:

# Use swap only if it is absolutely neccessary
vm.swappiness = 0

Die Änderungen werden nach einem Neustart wirksam, alternativ kann man auch die sysctl.conf neu einlesen lassen oder den Wert selbst einmalig in /proc/sys/vm/swappiness schreiben.

RAID?

Man kann natürlich auch auf RAID-Devices swappen, aber es ist nicht sinnvoll. Die Ausfallsicherheit oder gar Redundanz die man etwa bei einem RAID-1, RAID-5, RAID-6 oder RAID-10 gewinnt, bringen einem bei Swap überhaupt nichts, denn die Informationen in einem Swap braucht man nicht wiederherstellen, sie sind flüchtig. Ein RAID-1 würde allenfalls beim Lesen aus dem Swap etwas Tempo bringen, aber beim Schreiben bringt es keinen Gewinn, ähnliches gilt für RAID-10. Bei einem RAID-5 und RAID-6 muß zusätzlich die Berechnung der Paritätsinformation erfolgen, was das ganze weiter verlangsamt.

Und um gleich noch mit diesem Mythos aufzuräumen: RAID schützt nicht davor, daß auf der Festplatte Bits umkippen, die meisten RAID-Systeme können so etwas zwar erkennen, aber sie können es leider nicht behandeln (ein RAID-1 mit zwei Platten z.B. kann nicht erkennen, welcher der zwei Blöcke der richtige oder falsche ist). Wenn in benutzem Swap ein Bit umkippt, dann hat das die gleichen Konsequenzen, als wenn das im RAM passiert: das Programm oder sogar das Betriebssystem stürzt ab. Kein RAID-Level kann das zuverlässig verhindern, man kann sich mit Swap keinen Pseudo-ECC-RAM bauen. Da Daten aber selten lange im Swap liegen, ist die Wahrscheinlichkeit eines Bitflips äußerst gering, da sowas meist eher in Bereichen auftritt in denen sehr lange nicht auf die Platte geschrieben wurde.

Das einzige was bei Swap etwas bringen würde wäre ein RAID-0, bei dem man ein bißchen Performance gewinnt. Hier muß man sich aber nicht die Mühe machen, einen RAID-0 zu konfigurieren (der auch RAM belegt), das kann das Swap-Subsystem selbst und viel effizienter, indem man einfach zwei Swaps auf zwei Festplatten anlegt und sie mit gleicher Priorität einbindet (was zur Folge hat, daß beide gleichmäßig genutzt werden), z.B.:

/dev/sda3 swap swap defaults,pri=1 0 0
/dev/sdb3 swap swap defaults,pri=1 0 0

SSD?

Oh du liebe Zeit, nein!

Nein.

SSDs sind zwar gehörig schneller als Festplatten mit drehenden Scheiben, aber sie verkraften nur eine begrenzte Anzahl von Schreibzyklen. Auf eine SSD zu swappen ist ein sicherer Weg die teuren Dinger schnell abzunutzen. Wenn SSDs irgendwann mal billig sind (oder Geld kein Problem darstellt), dann kann man sicherlich darüber nachdenken, aber im Moment wäre es echt noch schade drum. (Derzeit kostet das Gigabyte Festplattenspeicher um die 3 Cent, das Gigabyte SSD-Speicher zwischen 1 und zwei Euro.)

Das Hauptproblem ist aber ein anderes: Wohl kaum jemand wird eine SSD erwerben und sie ausschließlich aus Swap verwenden. Das wäre aber das einzig sinnvolle. Man kann auf SSDs durchaus swappen, aber wenn man es tut, dann sollte der Rechner die SSD auch abnutzen dürfen. Den meisten dürfte es aber nicht schmecken, wenn durch die Abnutzung von 4 GiB Swap auf einer wesentlich größeren SSD auch der restliche Speicher auf dieser SSD kaputt gemacht wird, was aber leider der Fall wäre. Also wenn man auf eine SSD swappt, dann sollte man vielleicht doch lieber eine kleine nehmen, die dann nur für den Swap da ist und sich nicht seine 3.000 Euro teure 1T B SSD mitsamt allen anderen schönen Daten drauf ruinieren.

5 Antworten auf „Swap unter Linux, ein paar Notizen“

  1. Danke für die Aufklärung zu swappiness. Ich werde bei meinem Server mal versuchen, einen optimalen Wert zu finden.

  2. Frage zu Swap und SSD

    Eine Swap-Partition wäre nicht sinnvoll, da sich dieser Bereich schnell abnutzen würde. Ok.
    Aber eine swap-Datei auf einer SSD kombiniert mit einer niedrigen swappiness sollte doch ein guter Weg sein oder!? Hier sollte sich die Abnutzung über die ganze SSD verteilen, sodass die Lebensdauer nicht dramitisch sinkt. Bei einer hinreichend großen Platte sollte das kein Problem darstellen. Oder ist der Swap-Traffic so exorbitant.

    PS: Was macht Linux denn, wenn ich gar keinen Swap habe? Es müsste dann doch immer den entsprechend „am wenigsten genutzten“ Teil des RAM bei Bedarf frei räumen. Die normalerweise „ruhenden“ Daten würden dann vorworfen und müssen beim „aufwecken“ der entsprechenden Prozesses neu erzeugt werden, anstatt nur rübergeschoben, was eher einem Neustarten eines Programms/Prozesses gleichkommt.
    Wieviel Performance kostet es kein Swap zu haben? (Das hängt logischerweise vom System und der Nutzung ab, wieviel RAM, wieviele Programme laufen gleichzeitig usw. also ob swap überhaut genutzt wird. Aber eine ungefähre Aussage?)

    1. Hi Kalle, da der Blogpost von meinem Kollegen Chris stammt (der mit dem Themenbereich gleichzeitig am versiertesten von uns ist), überlasse ich die Antwort gerne ihm. Er ist allerdings gerade im Urlaub; kann also etwas dauern, sorry.

    2. Bei SSDs ändert sich die Technik leider immer noch so rasant, daß man kaum Aussagen darüber treffen kann, wie man mit ihnen umgehen soll. Bei älteren SSDs würde der Bereich in dem die SSD-Partition liegt verstärkt abgenutzt werden, bei neueren würde die SSD die Schreibzyklen intern über alle Blöcke verteilen und somit für eine gleichmäßige Abnutzung der SSD sorgen, die Abnutzung bliebe also nicht auf den Bereich der Swap-Partition beschränkt. Vernünftige SSDs sollten auch eine ganze Menge Schreibzyklen aushalten. Letztlich läuft es aber darauf hinaus, daß SSDs immer noch verdammt teuer sind und immer nur eine begrenzte Menge an Schreibzyklen vertragen werden. Mit der gleichen Argumentation könnte man aber auch davon abraten, sehr stark beschäftigte Datenbanken auf SSDs schreiben zu lassen.

      Wenn einem Swap so wichtig ist und man das Geld dafür hat, kann man das machen. Ggf. sollte man lieber mehrere SSDs verbauen und eine davon nur zum Swappen verwenden und für nichts anderes, damit ihre Abnutzung am Ende nicht zu Datenverlusten führt. Wenn ich die aktuellen RAM-Preise mit denen von SSDs vergleiche, dann würde ich mich klar für mehr RAM entscheiden und nicht dafür, eine SSD mit Swap zu belasten. Ich bin SSDs gegenüber aber auch noch etwas skeptisch eingestellt und würde sie wo immer möglich nur mit einer Festplatte zusammen einsetzen und alles was häufig und viel schreibt auf die Festplatte sortieren.

      Linux kann sehr gut auch ohne Swap auskommen. Der Swap dient zwei Zwecken:

      1.) Zunächst einmal kann Linux mit einem Swap selten bis gar nicht benutzte Pages aus dem RAM auslagern. Das ist insbesondere dann sinnvoll, wenn man etwa Programme einsetzt deren Funktionsumfang man nur teilweise nutzt. Ein typischer Fall wäre z.B. Evolution, wenn man es ausschließlich als Mail-Programm nutzt und die ganzen Kalender-Funktionen gar nicht benötigt. Linux könnte dieses Benutzungs-Muster erkennen und den durch die Kalender-Funktionalität belegten RAM in den Swap auslagern. Deswegen ist eine hohe Swappiness auf Desktops oft gar nicht so schlecht. Auch auf Servern kann es Fälle geben in denen das sinnvoll sein kann.

      2.) Wenn Linux akut der RAM ausgeht, kann es auch aktive Programme in den Swap verlagern und sich so etwas Luft verschaffen. Erfahrungsgemäß hilft das aber meist nicht für lange. Erstens wird der Rechner dann spürbar langsamer, zweitens ist damit das Problem daß irgendetwas viel zu viel RAM belegt meist nicht behoben. Ob mit Swap oder ohne, irgendwann kommt der Punkt wo der Kernel feststellt, daß er keinen Speicher mehr frei hat, also „out of memory“ (OOM) ist. Er wird dann anfangen Programmen zu befehlen sich zu beenden. Wenn alle Programme darauf reagieren, kann das Problem sich dadurch beheben. Auf einem Server bestünde sogar die Chance, daß die Programme danach wieder gestartet werden und alles wieder normal weiter läuft. Auf einem Desktop würde der Benutzer vermutlich fluchend vor dem Bildschirm sitzen und alsbald neustarten.

Kommentare sind geschlossen.