Arbeitsweise¶

Das im Kontext von Swap benutzte Verfahren "paging" wird für die Verwaltung des virtuellen Arbeitsspeichers benötigt. Linux stellt wie alle modernen Betriebssysteme den Prozessen den als Hardware verbauten Arbeitsspeicher nicht direkt zur Verfügung, sondern immer als virtuellen Speicher unter Verwendung einer speziell dafür vorgesehenen Einheit MMU (Memory Managment Unit) in der CPU. Jedem Anwendungsprogramm steht daher eine wesentlich größerer Adressbereich zur Verfügung als tatsächlich Arbeitsspeicher vorhanden ist. Nur ein Teil des versprochenen Adressbereiches wird aber mit echtem RAM hinterlegt. Ein Zugriff auf eine nicht mit echtem RAM hinterlegte Adresse löst einen speziellen Interrupt page_fault aus und die MMU muss nun nachbessern:

• Solange noch echter, nicht zugeteilter Arbeitsspeicher vorhanden ist, wird davon etwas an den auslösenden Prozess zugeteilt. Die Zuteilung erfolgt immer in Blöcken (pages) von meistens 4 kiB, auch Speicherseiten genannt.

• Wenn es keinen freien echten RAM mehr gibt, muss der Kernel etwas freiräumen. Dafür gibt es mehrere mögliche Maßnahmen:

  1. Es werden Speicherseiten gesucht, die zwar belegt, deren Inhalt aber wahrscheinlich gar nicht benötigt wird und wenn doch, dann problemlos durch Lesen aus einer vorhandenen Datei von einem Massenspeicher rekonstruierbar wäre. Das sind beispielsweise vom Kernel selbst belegte Puffer und Caches. Wenn das Erfolg verspricht, verzichtet der Kernel auf einen Teil des eigenen Arbeitsspeichers und teilt etwas vom freigewordenen RAM dem notleidenden Prozess zu. Dies ist die kostengünstigste Maßnahme.

  2. Außer Puffern und Caches gibt es auch noch Speicherseiten, die Teile einer Datei enthalten, die von einem Programm gelesen wird, aber selber nicht verändert wurden. Dazu gehören auch Speicherseiten mit ausführbarem Programmcode. Diese Speicherseiten sind ebenfalls später kostengünstig durch lesenden Zugriff auf den Massenspeicher rekonstruierbar. Diese Maßnahme ist etwas teurer als die erste, da es mit höherer Wahrscheinlichkeit tatsächlich später zum lesenden Zugriff auf den Massenspeicher kommen wird.

  3. Speicherseiten mit Arbeitsergebnissen von Programmen, z.B. geänderte, aber nicht nicht auf Massenspeicher geschriebene Dateien können nur zu höheren Kosten aus dem Arbeitsspeicher verdrängt werden: Es muss eine Zwischenspeicherung erfolgen, d.h. ein Schreibzugriff auf den Swap-Speicher und später mit Sicherheit ein weiterer lesender Zugriff auf den Massenspeicher.

  4. Wenn alle vorher genannten Maßnahmen nicht möglich sind, schickt der Kernel den OOM-Killer ("out of memory killer") los. Dieser wählt einen Prozess aus, killt ihn und liefert die seinem Opfer entrissenen Speicherseiten bei der MMU als zuteilbar ab. Aus Sicht des Anwenders wählt der OOM-Killer oft genug einen noch unverzichtbar benötigten Prozess aus, was dann in einem unbenutzbarem oder unbrauchbarem oder auch tatsächlich abgestürztem System endet. Selbst wenn das System diese verzweifelte Maßnahme überlebt, tritt immer unvermeidlich Datenverlust ein.

Die vorstehend vereinfacht beschriebene Arbeitsweise ignoriert einige Details, die für diesen Artikel keine Rolle spielen:

• Es kann mehr als einen Speicherpool geben. In der Regel existiert aber nur einer.

• Jeder Speicherpool wird unterteilt in Zonen, je nach Lage des Speichers im Adressbereich. Für 64-Bit-Systeme (d.h. außer 32-Bit-CPU, exotische Adressmodus, andere Sonderfälle) gibt es diese Zonen:

  • Adressen unter 16 MiB

  • Adressen ab 16 MiB bis unter 4 GiB

  • Adressen ab 4 GiB

• In jeder Zone gibt es Pools unterschiedlicher Größe, d.h. ganzzahligen Vielfachen der Blockgröße (meist 4 KiB).

• Ein Notstand tritt auf, wenn Arbeitsspeicher mit der angeforderten Größe und Zone nicht mehr verfügbar ist, auch wenn es noch massenweise freien Speicher mit anderer Stückelung gibt.

Man kann als Anwender eines Linux-Systems nicht verhindern, das irgendwann einmal die 4. Maßnahme zur Anwendung kommt. Man kann nur die Wahrscheinlichkeit dafür durch sinnvolle Maßnahmen verringern:

• Man baut genügend Arbeitsspeicher ein, damit die Maßnahmen 1 und 2 funktionieren und möglichst Maßnahme 3 gar nicht benötigt wird.

• Man stellt trotzdem mindestens einen Swap-Bereich zur Verfügung, damit Kernel und MMU die Maßnahme 3 überhaupt anwenden können.

• Den tatsächlichen Gebrauch des Swap-Speichers überwacht man. Wenn er nicht gebraucht werden, ist das kein Grund auf ihn zu verzichten. Wenn sein Gebrauch ansteigt, denkt man über den Einbau zusätzlichen Arbeitsspeichers nach und überdenkt auch sein eigenes Nutzungsverhalten.

• Andererseits ist Swap aber auch kein Ersatz für fehlenden Arbeitsspeicher. So etwas ist zwar technisch möglich und in seltenen Spezialfällen mag das auch sinnvoll sein, aber als Regel gilt: Wenn die Swap-Bereiche intensiv genutzt werden, hat man zu wenig Arbeitsspeicher.

Wenn man gar keinen Swap-Bereich definiert, kann der Zuteilungsalgorithmus für RAM im Linux Kernel die Maßnahme 3 nicht anwenden und ändert deshalb auch seine Arbeitsweise für die Maßnahmen 1 und 2. Er agiert vorsichtiger und damit möglicherweise auch langsamer, d.h. die reine Bereitstellung von Swap-Speicher verbessert bereits die Verwaltung des Arbeitsspeichers, auch wenn der Swap-Speicher gar nicht benutzt wird.

Swapgröße¶

Die passende Speichergröße kann nicht im Allgemeinen angegeben werden, weil sie von mehreren individuellen Faktoren abhängt:

• Größe des Arbeitsspeichers: Ein größerer Arbeitsspeicher ist ein valides Argument für eine Verkleinerung des SWAP-Speichers.

• Nutzungsart des Arbeitsspeichers (workload)

• Art des Massenspeichers (rotierende Magnetplatte oder SSD)

• Soll Suspend-to-Disk benutzt werden oder nicht? Wenn man Suspend-to-Disk benutzen möchte, gelten zusätzliche Restriktionen:

  • Man benötigt einen Auslagerungsbereich mit mindestens der Größe des Arbeitsspeichers.

  • Diesen Speicherbereich darf man nicht stückeln, sondern er muss fortlaufend beschreibbar sein.

Es gelten diese Regeln:

• Ein Swap-Speicher von 0 Bytes ist zu klein für jede Größe des Arbeitsspeichers.

• Die Größe des Swap-Speichers soll man so wählen, dass ihre dauerhafte Nutzung klein (z.B. unter 10%) bleibt.

• Ein zu großer Swap-Speicher schadet aber jedenfalls nicht; er fordert auch nicht das System heraus, ihn zu benutzen. Das gilt jedenfalls uneingeschränkt für Linux Kernel ab 4.0.

• Es gibt keine sinnvolle Kopplung der Größe des Swap-Speichers mit der Größe des Arbeitsspeichers, ausgenommen beim Einsatz von Suspend-to-Disk. Verbreitet aufgedrängte Rezepte wie „Swap-Speicher = halber Arbeitsspeicher“ o.ä. sind Relikte aus der Zeit, als noch wirklich "geswappt", d.h. Prozesse ausgelagert wurden und können nicht sinnvoll auf "paging" übertragen werden.

• Ein richtig konfigurierter Swap-Speicher, der im praktischen Einsatz nicht benutzt wird, ist eine gute Nachricht.

• Ein fehlender Swap-Speicher liefert einen Grund, den Systemverwalter zu entlassen, denn dieser geht ein zwar geringes, aber unnötiges Risiko für die Betriebssicherheit des von ihm verwalteten Systems ein.

Wer Suspend-to-Disk benutzen möchte oder sich die Möglichkeit dafür offen halten möchte, wählt „Größe des ersten Swap-Bereiches = tatsächlich verbauter RAM“. Man benötigt in der Regel keinen Zuschlag, weil das Speicherabbild für Hibernation komprimiert wird.

Wer Suspend-to-Disk nicht benutzen möchte, wählt z.B. „Größe des Swap-Speichers = 2 GiB“ und trifft Vorsorge, dies später bei Bedarf vergrößern zu können.

Swap anlegen¶

Ubuntu legt bei der Installation standardmäßig automatisch einen Swap-Bereich an, d.h. die meisten Benutzer müssen sich überhaupt nicht um dieses Thema kümmern. Man erhält dann eine Auslagerungsdatei im Wurzel-Dateisystem, was natürlich die Mindestgröße der dafür benutzten Partition etwas erhöht.

Einen neuen Swap-Bereich kann man als separate Partition oder als Datei anlegen. Man kann auch mehrere (bei Linux bis zu 32) Swap-Bereiche anlegen und gleichzeitig nutzen.

sudo partprobe 

sudo kpartx 

sudo apt-get install swapspace 

Dienstprogramme¶

Zur Verwaltung von Swap-Bereichen gibt es die Programme mkswap, swapon, swapoff und swaplabel aus dem Paket util-linux, welches bei allen Ubuntu-Systemen bereits bei der Errichtung mit installiert wird.

Jeder der vier genannten Befehle hat seine eigene Manpage.

sudo mkswap /dev/sda99 

sudo mkswap /swapfile 

Swapnutzung einstellen¶

Im Internet findet sich weit verbreitet die unzutreffende Behauptung, man könne über die Kernel-Variable vm.swappiness einstellen, ab welchem Belegungsgrad des realen RAM der Kernel Daten aus dem Arbeitsspeicher in den Swap-Speicher verschiebt. Tatsächlich wird eine solche Verdrängung stets erst dann erwogen, wenn kein Arbeitsspeicher (der angeforderten Größe und Lage) mehr zu vergeben ist und die oben im Abschnitt Arbeitsweise genannte Methode 3 angewendet werden muss.

Die Kernel-Variable vm.swappiness ist eine Feinabstimmung, über die man einstellen kann, welche Art von Speicherseiten bevorzugt ausgelagert werden soll, aber nicht, ob ausgelagert werden soll.

Für die Methode 3 kommen zwei Arten von Speicherseiten in Frage:

1. Teile von Dateien, die bereits auf Massenspeicher abgelegt wurden, aber im Arbeitsspeicher verändert wurden. Solche Speicherseiten (file_pages) werden beim "paging" nicht in einen Swap-Bereich ausgelagert, sondern in der Datei gespeichert, zu der sie gehören.

2. Arbeitsergebnisse von Programmen, z.B. für neue Dateien, die bisher noch gar nicht auf Massenspeicher gelangten. Solche Speicherseiten (anonymous_pages) werden beim "paging" in Swap-Bereiche ausgelagert.

Die Verfügbarkeit von Swap-Speicher erlaubt dem Kernel, diese beiden Arten von Speicherseiten gleichartig zu behandeln; dabei kann man über vm.swappiness die Priorisierung steuern.

Für vm.swappiness kann man einen Wert von 0 bis 200 angeben, und diese Variable bestimmt zwei Werte:

• ein Maß für die Priorität der "anonymous_pages" = vm.swappiness (≙ 30% beim Standardwert 60)

• ein Maß für die Priorität der "file_pages" = 200 - vm.swappiness (≙ 70% beim Standardwert 60)

(Die tatsächliche Berechnung im Kernel ist komplizierter, führt aber am Ende auf diese Situation.)

Den aktuellen Wert kann man mit dem Befehl

sysctl vm.swappiness 

abfragen. Der Standardwert ist 60, somit lagert der Kernel mit einer Wahrscheinlichkeit von 70% Seiten von benannten Dateien und zu 30% anonyme Seiten aus. Dieser Wert ist ein langjährig in der Praxis erprobter Kompromiss über unterschiedliche Einsatzszenarien. Der für das eigene System optimale Wert hängt ab vom konkreten Nutzungsverhalten (workload) und kann nur durch systematische Erprobung ermittelt werden.

Die Erprobung ist zeitaufwändig. Man benötigt für aussagekräftige Ergebnisse mindestens eine Woche Betrieb pro testweise eingestelltem Wert und muss natürlich in diesem Zeitraum sowohl das typische Nutzungsverhalten, aber auch Situationen mit tatsächlicher Anforderung des Swap-Speichers reproduzierbar nachstellen.

Wer die Erprobung durchführen will, startet zweckmäßig mit einer Einstellung der gleichen Wahrscheinlichkeit von 50% für beide Arten von Speicherseiten.

Die Kernel-Variable kann man so ändern:

• Sofort, aber temporär bis zum Neustart mit dem Befehl:

  sudo sysctl vm.swappiness=100 

• Beim Neustart durch eine Eintragung in der Datei /etc/default/grub als Bootoption,

• oder indem man mit Rootrechten^[2] eine Systemdatei anlegt:
  

  # /etc/sysctl.d/vm.swappiness=100.conf 
  vm.swappiness=100

Ein valider Grund zur eigenen Einstellung von vm.swappiness sind Vorgaben von Datenbank-Systemen.

Swap überwachen¶

Es gibt mehrere Methoden zu Überwachung der tatsächlichen Nutzung des SWAP-Speichers:

• Grafische Werkzeuge:

  • Bei Gnome startet man die Systemüberwachung, z.B. aus dem Menü „Anwendungen → Systemwerkzeuge → Systemüberwachung“ oder aus dem Übersichtsmodus durch Suche nach Systemüberwachung (meist reichen einige Anfangsbuchstaben) und Klick auf das Icon.

  • Bei KDE ist ein Systemmonitor im Menü in „Programme → System → Systemmonitor“ zu finden, der Reiter Systemlast zeigt mitunter auch die Swapnutzung an.

  • Unter Xfce kann man sich die Belegung von Swap anzeigen lassen, in dem man das Programm „System → Task Manager“ startet. Oder indem man das Plugin "Systemauslastung" zum Xfce Panel hinzufügt.

• Kommandozeile:

  • vmstat zeigt die durchschnittliche Nutzung seit Systemstart oder seinem letzten Aufruf und kann auch die Anzeige kontinuierlich aktualisieren,

  • alternativ top.

  • free zeigt einmalig die über alle Prozesse und Swap-Bereiche summierte Nutzung,

  • ebenso wie, jedoch aufgelöst nach SWAP-Bereichen:

    swapon --show 

  • Eine weitere Möglichkeit:

    cat /proc/swaps 

    Die folgende Beispielausgabe zeigt eine definierte Swap-Datei, die auch tatsächlich verwendet wird und eine Swap-Partition als zweiten Swap-Bereich:
    

    Filename				Type		Size		Used		Priority
    /swapfile                               file    	2191356		1272716		-2
    /dev/sda4                               partition	5242876		0		-3

  • Für einen einzelnen Prozess mit der beispielhaften PID 4712 erfährt man die Nutzung von SWAP und anderer Nutzung von Arbeitsspeicher aus der Datei /proc/4712/smaps. Wenn man nicht selbst Besitzer dieses Prozesses ist, muss man sudo benutzen. Zweckmäßigerweise benutzt man für solche Abfragen das Skript swapstat:

    • Beschreibung und Anleitung

    • direkter Download:swapstat ⮷

  • Da das Initialisierungssystem systemd für jedes in der Datei /etc/fstab aufgeführte Dateisystem auch automatisch eine Unit anlegt, kann man auch diese zur Abfrage verwenden:

    systemctl status dev-sda4.swap 

    Beispielausgabe:
    

    dev-sda4.swap - /dev/sda4
         Loaded: loaded (/etc/fstab; generated)
         Active: active since Sun 2024-12-15 12:29:42 CET; 6h ago
           What: /dev/sda4
           Docs: man:fstab(5)
                 man:systemd-fstab-generator(8)
          Tasks: 0 (limit: 9321)
         Memory: 8.0K (peak: 600.0K)
            CPU: 4ms
         CGroup: /system.slice/dev-sda4.swap

    Man erhält hier nicht nur den momentanen Wert (inkl. Overhead), sondern auch einen Eindruck der bisherigen Nutzung seit der letzten Aktivierung dieses Swap-Bereiches.

Swap leeren¶

Ein benutzter Swap-Bereich wird in der Regel im laufenden Betrieb nicht wieder geleert. Wenn man ihn leeren will, muss man ihn abmelden (→ Swap-Bereich deaktivieren) und erneut anmelden (→ swapon)

Swap deaktivieren¶

systemctl --type swap --all 

systemctl stop dev-sda4.swap 

sudo swapoff /dev/sda4 

grep swap /etc/fstab 

#/dev/sda4					none		swap	nofail 

/dev/sda4					none		swap	noauto 

systemctl mask "dev-sda4.swap" 

swaplabel /dev/sda4
lsblk -oname,label,uuid,partlabel,partuuid /dev/sda4

Links¶

• Virtual_memory – virteller Arbeitsspeicher bei Wikipedia

• Memory Management 🇬🇧 Kapitel im "The Linux kernel user’s and administrator’s guide" der offiziellen Linux-Dokumentation

• Understanding the Linux Virtual Memory Manager 🇬🇧 – Open Source Book von Mel Gorman, Stand 2007

• https://wiki.debian.org/Swap 🇬🇧 – Swap im Debian-Wiki

• Swap FAQ 🇬🇧

• Skripte/UUID anpassen mit uuid2swap – Skript zur Korrektur falscher UUID der Swap-Partition

• Swap/swapstat – Skript zur Abfrage der Nutzung von Swap pro Prozess