Swap-Konfiguration und Swappiness richtig einstellen

1. Swap im Kontext moderner Server

Swap ist ein Bereich auf der Festplatte oder SSD, den der Linux-Kernel als Erweiterung des physischen Arbeitsspeichers nutzt. Wird der RAM knapp, lagert der Kernel selten genutzte Speicherseiten dorthin aus und schafft so Platz für aktive Prozesse. In Zeiten von Servern mit 64 oder 128 GB RAM und schnellen NVMe-SSDs klingt das nach einem Relikt aus der Ära knapper Arbeitsspeicherpreise, tatsächlich bleibt Swap aber auch auf modernen Systemen ein wichtiges Sicherheitsnetz.

Ohne Swap greift bei einem Speicherengpass sofort der Out-of-Memory-Killer des Kernels und beendet Prozesse hart, oft ausgerechnet den speicherhungrigsten und damit wichtigsten Dienst. Mit ausreichend Swap gewinnt das System wertvolle Sekunden, um kurzzeitige Lastspitzen abzufedern, etwa bei einem Backup-Lauf, einem Cache-Warmup oder einem Speicherleck, das noch nicht bemerkt wurde. Swap ist zudem Voraussetzung für Hibernation, bei der der komplette Speicherinhalt vor dem Herunterfahren auf die Platte geschrieben wird. Die eigentliche Kunst liegt nicht darin, ob Swap aktiviert wird, sondern wie viel und mit welchem Verhalten.

2. Wie viel Swap ist heute sinnvoll

Die alte Faustregel doppelte RAM-Größe als Swap stammt aus einer Zeit, in der Arbeitsspeicher im einstelligen Gigabyte-Bereich lag und Auslagerung häufig vorkam. Auf einem heutigen Server mit 32 GB oder mehr RAM würde diese Regel ein Swapfile von 64 GB verlangen, das in der Praxis kaum je vollständig genutzt wird und nur unnötig Plattenplatz belegt. Distributionen wie Red Hat und Ubuntu empfehlen inzwischen gestaffelte Werte: bis 2 GB RAM das Doppelte als Swap, zwischen 2 und 8 GB RAM eine Swap-Größe gleich dem RAM, darüber hinaus reichen meist 4 bis 8 GB als Sicherheitsnetz, sofern keine Hibernation genutzt wird.

Wer Hibernation braucht, muss Swap mindestens so groß wie den RAM plus einen Puffer für den Kernel-Zustand einplanen, da der komplette Speicherinhalt hineinpassen muss. Datenbankserver mit viel Page-Cache-Bedarf profitieren oft von wenig bis gar keinem Swap in Kombination mit einer niedrigen Swappiness, während Anwendungsserver mit vielen kurzlebigen Prozessen von etwas mehr Puffer profitieren. Die Dimensionierung ist also immer eine Funktion aus RAM-Größe, Workload-Typ und der Frage, ob Hibernation überhaupt relevant ist.

# cloud-init: automatically create a swapfile on first boot
# Useful for cloud VMs where the base image ships without swap
swap:
  filename: /swapfile
  size: "4294967296"     # 4G in bytes, or "auto" to let cloud-init decide
  maxsize: "4294967296"

3. vm.swappiness: was der Parameter wirklich steuert

Der Kernel-Parameter vm.swappiness steuert, wie stark der Kernel dazu neigt, anonyme Speicherseiten auszulagern statt Page-Cache-Einträge freizugeben, wenn beides möglich wäre. Der Wertebereich reicht historisch von 0 bis 100 und wurde ab Kernel 5.8 auf bis zu 200 erweitert, um noch aggressiveres Auslagern zu ermöglichen. Der Standardwert liegt meist bei 60 und ist ein Kompromiss für Desktop-Systeme, nicht für spezialisierte Serverlasten.

Ein häufiges Missverständnis: Swappiness ist keine Prozent-Schwelle, ab der ausgelagert wird, sondern eine relative Gewichtung zwischen zwei Reclaim-Strategien des Kernels. Ein Wert von 0 bedeutet nicht, dass niemals ausgelagert wird, sondern nur, dass der Kernel Page-Cache so lange wie möglich bevorzugt und erst im äußersten Notfall auf Swap zurückgreift. Ein Wert von 100 bedeutet, dass anonyme und dateibasierte Seiten gleichwertig behandelt werden. Für Datenbankserver wie MySQL oder PostgreSQL, deren Performance stark vom Page-Cache abhängt, empfiehlt sich ein niedriger Wert zwischen 1 und 10. Für Systeme mit viel freiem RAM und seltenen Lastspitzen kann der Standardwert unverändert bleiben.

# /etc/sysctl.d/99-swappiness.conf
# Lower swappiness favours page cache over swapping anonymous pages
vm.swappiness = 10

# Reduce cache pressure so directory/inode caches survive memory pressure longer
vm.vfs_cache_pressure = 50

# Reserve a small watermark so the kernel starts reclaiming before OOM
vm.min_free_kbytes = 65536

Nach dem Anlegen der Datei wird die Konfiguration mit sysctl --system geladen, ohne dass ein Neustart nötig ist. Wichtig: Änderungen per sysctl vm.swappiness=10 auf der Kommandozeile gelten nur bis zum nächsten Reboot, dauerhaft wirksam wird die Einstellung ausschließlich über eine Datei unter /etc/sysctl.d/.

4. Ein Swapfile anlegen und aktivieren

Ein Swapfile lässt sich ohne Neustart und ohne Partitionierung einrichten, was es zur bevorzugten Methode auf Cloud-Instanzen und Container-Hosts macht. Der erste Schritt ist die Reservierung des Speicherplatzes mit fallocate, was auf den meisten Dateisystemen deutlich schneller ist als dd, weil keine Nullen tatsächlich geschrieben werden müssen. Auf Btrfs funktioniert fallocate für Swapfiles jedoch nicht zuverlässig, dort muss dd mit bs=1M verwendet werden, da Copy-on-Write und Swap-Dateien sich grundsätzlich nicht vertragen und eine eigene No-Copy-on-Write-Attribut-Behandlung nötig ist.

Nach der Reservierung müssen die Dateirechte auf 600 gesetzt werden, damit kein anderer Benutzer den potenziell sensiblen Speicherinhalt lesen kann. Anschließend formatiert mkswap die Datei mit der Swap-Signatur, und swapon aktiviert sie sofort für die laufende Sitzung. Damit die Swap-Datei auch nach einem Neustart aktiv bleibt, muss ein Eintrag in /etc/fstab ergänzt werden. Ein abschließender Blick mit swapon --show und free -h bestätigt, dass der Kernel die neue Swap-Fläche tatsächlich erkannt hat und sie zur Verfügung steht.

#!/usr/bin/env bash
# Reserve 4G, prefer fallocate (instant), fall back to dd on Btrfs
sudo fallocate -l 4G /swapfile || sudo dd if=/dev/zero of=/swapfile bs=1M count=4096

# Restrict permissions before the swap signature is written
sudo chmod 600 /swapfile

# Write the swap signature and enable it for the running session
sudo mkswap /swapfile
sudo swapon /swapfile

# Persist across reboots
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

# Verify the kernel sees the new swap area
swapon --show
free -h

5. Swap-Partition versus Swapfile

Früher war die Swap-Partition die einzig empfohlene Variante, weil Swapfiles auf fragmentierten Dateisystemen theoretisch langsamer sein konnten und ältere Kernel Swap-Dateien nur eingeschränkt unterstützten. Seit den Kernel-Versionen der letzten Jahre ist dieser Performance-Unterschied auf SSDs und NVMe-Speicher praktisch nicht mehr messbar, weshalb moderne Distributionen wie Ubuntu seit Version 17.04 standardmäßig ein Swapfile statt einer Partition anlegen.

Der entscheidende Vorteil eines Swapfiles ist Flexibilität: Die Größe lässt sich jederzeit mit swapoff, Anpassen der Datei und erneutem swapon ändern, ohne die Partitionstabelle anzufassen oder das System neu zu partitionieren, was bei einer Partition praktisch unmöglich ist, ohne Daten zu verschieben. Cloud-Images und Container-Basis-Systeme bieten aus genau diesem Grund meist gar keine dedizierte Swap-Partition an. Eine Swap-Partition bleibt sinnvoll, wenn ein System mit Full-Disk-Encryption läuft und Suspend-to-Disk zuverlässig funktionieren muss, da manche Bootloader-Konfigurationen eine Partition für den Resume-Vorgang voraussetzen. Für den überwiegenden Teil der Serverszenarien ist ein Swapfile heute die pragmatischere Wahl.

6. Swap-Nutzung beobachten: free, vmstat, /proc/meminfo

Die reine Kennzahl, wie viel Swap gerade belegt ist, ist für sich genommen wenig aussagekräftig. Aussagekräftiger sind die Ein- und Auslagerungsraten, die vmstat 1 in den Spalten si (swap in) und so (swap out) pro Sekunde anzeigt. Zeigen diese Werte dauerhaft Aktivität über mehrere Sekunden, tauscht der Kernel aktiv Seiten hin und her, was auf echten Speicherdruck hindeutet. Ein einmaliger Ausschlag beim Systemstart oder nach einem großen Batch-Job ist dagegen unauffällig.

Der Befehl free -h liefert einen schnellen Überblick über genutzten, freien und im Cache gehaltenen Speicher sowie den aktuellen Swap-Stand, während /proc/meminfo mit den Feldern SwapTotal, SwapFree und SwapCached die Rohdaten für eigene Monitoring-Skripte bereitstellt. SwapCached ist dabei besonders interessant: Es zeigt Seiten, die sowohl im RAM als auch im Swap liegen und bei erneutem Bedarf ohne Festplattenzugriff zurückgeholt werden können. Für historische Trends eignet sich sar -S aus dem sysstat-Paket, das die Swap-Nutzung über die Zeit protokolliert und rückwirkend Auswertungen über Tage oder Wochen erlaubt, ohne dass ein externes Monitoring-System nötig wäre.

# Live swap in/out activity, columns si and so (KB per second)
vmstat 1 5

# Quick overview: used, free, cached memory and current swap usage
free -h

# Raw kernel counters for custom monitoring scripts
grep -E 'SwapTotal|SwapFree|SwapCached' /proc/meminfo

# Historical swap usage trend (requires the sysstat package)
sar -S 1 10

7. Wann Swapping normal ist und wann nicht

Ein weit verbreitetes Missverständnis lautet: Swap wird benutzt, also hat der Server zu wenig RAM. Das ist in dieser Pauschalität falsch. Der Kernel lagert proaktiv selten genutzte anonyme Seiten aus, um mehr Platz für Page-Cache zu schaffen, der Dateizugriffe beschleunigt. Ein moderat gefüllter Swap-Bereich bei gleichzeitig niedriger si/so-Rate in vmstat ist normales, gesundes Verhalten und kein Grund zur Sorge.

Ein echtes Problem liegt vor, wenn si und so dauerhaft hohe Werte zeigen, die Load Average steigt, obwohl die CPU-Auslastung selbst niedrig bleibt, und die iowait-Zeit in top oder mpstat deutlich zunimmt. Dieses Muster nennt man Thrashing: Der Kernel tauscht ständig Seiten aus und wieder ein, statt produktiv zu arbeiten, und die gefühlte Reaktionszeit des Systems bricht spürbar ein. Seit Kernel 4.20 liefert Pressure Stall Information unter /proc/pressure/memory ein noch präziseres Signal als vmstat: Der Wert full zeigt an, wie viel Prozent der Zeit alle Tasks gleichzeitig auf Speicher warten mussten, ein direkter Indikator für echten Speicherdruck statt bloßer Interpretation von Rohwerten.

{
  "check": "swap_pressure",
  "interval_seconds": 30,
  "thresholds": {
    "swap_used_percent_warn": 60,
    "swap_used_percent_crit": 90,
    "vmstat_si_so_sustained_kb_s": 500,
    "pressure_memory_full_percent": 10
  },
  "action": {
    "warn": "log",
    "crit": "page_oncall"
  }
}

8. Zram und zswap als moderne Ergänzung

Zram und zswap adressieren dasselbe Grundproblem aus zwei verschiedenen Richtungen: Beide nutzen Kompression, um die effektive Kapazität des Arbeitsspeichers zu erhöhen, bevor überhaupt auf langsamere Datenträger ausgelagert wird. Zram erstellt ein komprimiertes Blockgerät direkt im RAM, das als vollwertiges Swap-Device eingebunden wird. Da Kompression und Dekompression deutlich schneller sind als ein Zugriff auf Festplatte oder selbst NVMe-SSD, eignet sich Zram besonders für Systeme mit wenig RAM, etwa kleine Cloud-Instanzen oder Container mit engen Memory-Limits.

Zswap arbeitet als komprimierter Zwischenspeicher vor dem eigentlichen Swap-Gerät: Seiten werden zunächst komprimiert im RAM gehalten und erst bei anhaltendem Speicherdruck endgültig auf die Platte geschrieben. Das kombiniert die Geschwindigkeit von Zram mit der praktisch unbegrenzten Kapazität eines klassischen Swapfiles als Fallback. Der Trade-off bei beiden Ansätzen ist CPU-Zeit für die Kompression, was auf Systemen mit knappen CPU-Ressourcen gegen die Ersparnis an I/O-Wartezeit abgewogen werden muss. Auf modernen Multi-Core-Servern überwiegt der Vorteil in der Praxis fast immer, insbesondere bei Workloads mit vielen kleinen, gut komprimierbaren Speicherseiten.

9. Swap-Konfiguration im direkten Vergleich

Die Wahl zwischen Swapfile, Swap-Partition, Zram und einer minimalen oder gar keiner Swap-Konfiguration hängt stark vom konkreten Einsatzszenario ab. Es gibt keine einzelne richtige Antwort, sondern nur die passende Kombination aus Workload-Typ, verfügbarem RAM und Ausfalltoleranz. Die folgende Tabelle stellt typische Fehlkonfigurationen den empfohlenen Einstellungen gegenüber und zeigt, warum die jeweilige Wahl in der Praxis den Unterschied macht.

In der Praxis liefert eine kurze Checkliste vor jedem Deployment die meiste Sicherheit: Workload-Typ kennen, Swappiness bewusst setzen statt beim Standardwert zu belassen, Swap-Fläche an RAM-Größe und Hibernation-Bedarf anpassen und Monitoring auf Auslagerungsraten statt auf die reine Swap-Belegung ausrichten.

10. Zusammenfassung

Swap ist auf modernen Servern kein Relikt, sondern ein bewusst konfigurierbares Sicherheitsnetz gegen den Out-of-Memory-Killer und kurzzeitige Lastspitzen. Die richtige Größe ergibt sich aus RAM-Kapazität, Workload-Typ und der Frage, ob Hibernation benötigt wird, nicht aus der pauschalen Verdopplungsregel vergangener Jahrzehnte. Der Kernel-Parameter vm.swappiness steuert die relative Gewichtung zwischen Page-Cache und anonymen Seiten und sollte für Datenbankserver bewusst auf einen niedrigen Wert gesetzt werden, statt beim Standardwert 60 zu bleiben. Ein Swapfile lässt sich mit fallocate, mkswap und swapon in wenigen Minuten ohne Neustart einrichten und ist auf den meisten Systemen der Swap-Partition inzwischen ebenbürtig.

Für die Diagnose zählt nicht die absolute Swap-Belegung, sondern die Ein- und Auslagerungsrate in vmstat sowie das PSI-Signal unter /proc/pressure/memory. Moderate Swap-Nutzung bei niedriger si/so-Rate ist normales Caching-Verhalten des Kernels, dauerhaft hohe Raten bei steigender Load Average signalisieren echtes Thrashing und akuten Speicherdruck. Zram und zswap bieten auf speicherknappen Systemen eine schnellere Alternative oder Ergänzung zum klassischen Festplatten-Swap, indem sie Kompression nutzen, bevor überhaupt auf langsamere Datenträger ausgelagert wird.

11. FAQ: Swap-Konfiguration und Swappiness