Swap deaktivieren oder beibehalten?

In einer Zeit, in der Arbeitsspeicher rar war, nutze man eine Auslagerungspartition oder -datei um nicht benötigte Teile des Arbeitsspeichers auszulagern. Dieser Auslagerungsspeicher (kurz Swap) ist auf aktuellen IT-Systemen und gerade unter Linux noch immer weit verbreitet.

Bei der aktuellen Menge an verfügbarem Arbeitsspeicher ist es selten erforderlich, diese Funktion zu nutzen. Also auf Swap in Servern verzichten und den freien Plattenplatz anderweitig nutzen? Nein!

Auch bei großen Mengen an Arbeitsspeicher oder an die zu betreibenden Dienste angepasster Menge an Arbeitsspeicher macht ein Page Cache und eine Auslagerungsdatei als Fangnetz für Notfälle Sinn. Fordert eine Anwendung mehr Arbeitsspeicher an als verfügbar ist, startet sonst der Out-of-Memory Killer und beendet zwangsweise Anwendungen.

Mit diesem Wissen macht es also sehr wohl Sinn, eine kleine Auslagerungspartition mit zum Beispiel 512MiB einzurichten und die Nutzung zu überwachen. Wird die Partition genutzt, kann dies als Hinweis auf eine Überlastsituation herangezogen werden. Um den Swap so zu nutzen, macht es Sinn das System so zu konfigurieren, dass es den Swap nur in Notfällen nutzt. Und das geht wie folgt.

# Minimal Swapping - s. https://en.wikipedia.org/wiki/Swappiness
echo "vm.swappiness = 1" >> /etc/sysctl.conf
sysctl -p
swapoff -a
swapon -a

2 Gedanken zu „Swap deaktivieren oder beibehalten?“

  1. Weiß jemand, wie sich deaktiviertes swapping auf die Energiespar-modi auswirken? Mir war immer so, als wenn suspend-to-ram und hibernate dafür die swap partitition nutzen, oder liege ich da falsch?

  2. Im Wesentlichen schlägst du vor, den vom Swapping verursachten massiven Slowdown des Systems für Monitoring zu missbrauchen. :-) Wäre es stattdessen nicht sinnvoller, die 512MB dem System in Form von echtem RAM statt Swap zu geben? Dann könntest du dein Monitoring so einstellen, dass es dich warnt, wenn du in diesen Pufferbereich kommst. Du bekommst so immer noch die „Notsituation“ mit, aber das System bleibt schnell.

    Was mir beim Thema Swap oft fehlt, ist, dass manche Operationen den gesamten virtuellen Speicher in Betracht ziehen und nicht nur den RAM. Zum Beispiel: Angenommen, du hast ein System mit 1GB RAM. Angenommen weiterhin, du hast jetzt einen Prozess laufen, der 800MB Speicher belegt hat. Was passiert nun, wenn dieser Prozess forken möchte?

    Linux schaut sich an, wieviel Speicher noch verfügbar ist. Ist dieser Wert unter einem bestimmten Schwellenwert, verweigert es den Fork. Dabei rechnet es RAM und Swap zusammen.

    Der Witz an der Sache ist, dass so gut wie jedes Programm die Kombination aus fork() und exec() benutzt, um irgendein anderes Programm zu starten. Beim Fork wird der Prozess kopiert (und damit auch sein Speicher), beim Exec wird aber das Programm durch ein anderes ersetzt (und damit die Speicherkopie wieder weggeworfen). Und außerdem macht Linux eh Copy-on-Write, sprich, beim Fork wird der Speicher gar nicht kopiert, sondern erst dann, wenn der Kindprozess ihn verändern möchte. Sprich, das hypothetische Programm mit seinen 800MB könnte ganz legitim forken und execen und damit ein ganz kleines anderes Programm ausführen wollen, sodass – Knackpunkt – die 1GB-Grenze insgesamt gar nicht überschritten werden würde.

    Hat das System aber nur 1GB RAM, dann verweigert Linux den Fork. Hat es hingegen 1GB RAM plus eine gewisse Menge an Swap, dann funktioniert der Vorgang. Und der Witz: Der Swap wurde nie benutzt. Linux musste nur sehen, dass insgesamt „genug“ Speicher vorhanden ist.

    Solche Grenzfälle sind interessant und man sollte sich das genauer anschauen. Sicher kann man auch einstellen, wie groß solche Schwellenwerte sind.

    Ganz allgemein würde ich im Jahre 2016, wo wir mit den Gigabytes nur so um uns werfen, aber sagen: Probier’s erstmal ohne Swap. In sehr, sehr vielen Fällen wird das wunderbar funktionieren und du hast keinen Swap-Slowdown.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.