Bewährte Methoden zur Optimierung des Linux-Swap-Verhaltens und des Cache-Verhaltens

Linux verwendet freien RAM. Das überrascht Leute, wenn sie zum ersten Mal einen Server mit sehr wenig "freiem" Speicher in free -h sehen. Der Großteil dieses Speichers kann Page-Cache, Dentries und Inode-Cache sein, kein Leck. Die schwierige Frage ist, wann der Kernel den RAM gut nutzt und wann die Speicherrückgewinnung beginnt, Ihre Anwendungen zu beeinträchtigen.

Zwei sysctl-Einstellungen tauchen oft bei der Linux-Speicheroptimierung auf: vm.swappiness und vm.vfs_cache_pressure. Sie sind nützlich, aber keine magischen Leistungsschalter. Ein schlechter Wert kann das eigentliche Problem verbergen oder die Belastung von einer Arbeitslast auf eine andere verschieben.

Grundlegendes zu den Parametern der Linux-Speicherverwaltung

Linux verwendet Heuristiken, um zu entscheiden, welche Speicherseiten zurückgewonnen werden sollen, wenn das System mehr freien RAM benötigt. Die beiden Hauptbereiche, die von Kernelparametern gesteuert werden, sind Swapping (Verschieben inaktiver Speicherseiten auf die Festplatte) und Caching (Halten von Dateisystem-Metadaten und -Daten im RAM).

1. `vm.swappiness`

vm.swappiness bestimmt die Tendenz des Kernels, Prozesse aus dem physischen Speicher auf den Swap-Speicher auf der Festplatte zu verschieben. Es ist ein Wert zwischen 0 und 100.

Höherer Wert (z. B. 60, ein üblicher Standardwert): Der Kernel ist eher bereit, anonymen Speicher zurückzugewinnen und Swap als Teil der normalen Speicherverwaltung zu verwenden. Dies kann den Page-Cache erhalten, aber auch latenzempfindliche Dienste beeinträchtigen, wenn aktive Seiten ausgelagert werden.
Niedriger Wert (z. B. 10 oder weniger): Der Kernel zieht es vor, Speicher aus dem Page-Cache zurückzugewinnen, bevor er beginnt, Prozesse auszulagern. Dies hält laufende Anwendungen länger im RAM, verbessert die Reaktionsfähigkeit, kann aber die Festplatten-E/A-Leistung beeinträchtigen, wenn das System ständig Cache-Seiten verwerfen muss.
Wert von 0: Der Kernel vermeidet Swapping so weit wie möglich, aber dies deaktiviert Swap nicht. Wenn Sie Swap deaktivieren müssen, verwenden Sie swapoff und verstehen Sie das Risiko eines Speichermangels zuerst.

Praktische Anwendung von `vm.swappiness`

Die optimale Einstellung hängt stark von der Arbeitslast ab:

Arbeitslasttyp	Empfohlener `swappiness`-Bereich	Begründung
Datenbankserver, Hochleistungsrechnen (HPC)	1 - 10	Oft ein guter Ausgangspunkt, wenn Swap-Latenz schlimmer ist als das Verwerfen von Cache. Mit realen Arbeitslastmetriken validieren.
Allzweckserver, Desktops	30 - 60	Normalerweise angemessen, es sei denn, Sie haben Hinweise, dass das Swap-Verhalten Ihnen schadet.
Dateiserver oder cache-lastige Systeme	60 oder höher in einigen Fällen	Kann den Page-Cache erhalten, ist aber nur sinnvoll, wenn gelegentliches Swapping für die Arbeitslast akzeptabel ist.

So überprüfen Sie den aktuellen Wert:

cat /proc/sys/vm/swappiness

So ändern Sie den Wert vorübergehend (bis zum Neustart):

Um swappiness auf 10 zu setzen:

sudo sysctl vm.swappiness=10

So ändern Sie den Wert dauerhaft:

Bearbeiten Sie die Datei /etc/sysctl.conf und fügen Sie die Zeile hinzu oder ändern Sie sie:

# /etc/sysctl.conf
vm.swappiness = 10

Nach dem Speichern wenden Sie die Änderungen ohne Neustart an mit:

sudo sysctl -p

Für speicherintensive Datenbanken ist 1 bis 10 ein üblicher Ausgangspunkt. Behandeln Sie es nicht als Regel. Eine Datenbank, die bereits einen eigenen Puffer-Cache hat, wie PostgreSQL oder MySQL/InnoDB, profitiert normalerweise davon, Swapping zu vermeiden. Ein Dateiserver bevorzugt möglicherweise einen größeren Page-Cache. Eine kleine VM mit zu wenig RAM wird leiden, egal welche Zahl Sie wählen.

2. `vfs_cache_pressure`

vfs_cache_pressure steuert, wie aggressiv der Kernel Speicher zurückgewinnt, der für Verzeichnis- und Inode-Metadaten (den VFS-Cache) verwendet wird.

Dieser Wert reicht von 0 bis 1000.
Der Standardwert ist normalerweise 100.

Bei einem Wert von 100 balanciert der Kernel die Rückgewinnung von VFS-Cache-Speicher gegen die Rückgewinnung von Speicher, der vom Page-Cache (Festplattendaten) verwendet wird. Ein Wert von 100 bedeutet, dass der Kernel bei Speicherdruck versucht, 1 Teil Inode/Dentry-Cache-Speicher für jeden 1 Teil Page-Cache-Speicher zurückzugewinnen.

Anpassen von `vfs_cache_pressure`

Erhöhen des Werts (z. B. > 100): Macht den Kernel aggressiver bei der Rückgewinnung von VFS-Cache-Speicher. Dies gibt RAM schneller frei, kann aber zu langsameren nachfolgenden Dateisystem-Lookups führen, da die Metadaten erneut von der Festplatte gelesen werden müssen.
Verringern des Werts (z. B. < 100): Macht den Kernel konservativer bei der Rückgewinnung von VFS-Cache. Dies hält Verzeichnis- und Inode-Informationen länger im Speicher und beschleunigt wiederholte Dateisystemoperationen.

Wann vfs_cache_pressure verringert werden sollte:

Wenn Ihr System häufig auf dieselben großen Verzeichnisstrukturen zugreift (häufig in komplexen Anwendungen, Container-Orchestrierung oder bestimmten Netzwerkkonfigurationen), kann das Setzen dieses Werts niedriger (z. B. 50) die Leistung verbessern, indem Metadaten leicht verfügbar im RAM gehalten werden.

Wann vfs_cache_pressure erhöht werden sollte:

Wenn Ihr System unter allgemeinem Speicherdruck leidet und Sie möchten, dass der Kernel jeden ungenutzten Speicher schnell zurückgewinnt, könnten Sie diesen Wert erhöhen, obwohl dies weniger üblich ist als das Verringern.

So überprüfen Sie den aktuellen Wert:

cat /proc/sys/vm/vfs_cache_pressure

So ändern Sie den Wert dauerhaft:

Bearbeiten Sie /etc/sysctl.conf:

# /etc/sysctl.conf
vfs_cache_pressure = 50

Wenden Sie Änderungen mit sudo sysctl -p an.

Warnung: Sehr niedrige vfs_cache_pressure-Werte können dazu führen, dass der Kernel Verzeichnis- und Inode-Cache länger hält als erwartet. Das kann metadatenintensiven Arbeitslasten helfen, kann aber den Speicherdruck für Anwendungen verschlimmern. Vermeiden Sie extreme Werte, es sei denn, Sie haben die Auswirkung gemessen.

Umfassende Optimierungsszenarien

Die Wahl der richtigen Kombination dieser Parameter optimiert den Kompromiss zwischen Anwendungsstabilität und Dateisystem-Caching.

Szenario 1: Datenbankserver (Speicherpriorität)

Ziel: Maximieren Sie die Anwendungsspeicherresidenz; minimieren Sie Swapping um jeden Preis.

vm.swappiness = 5
vfs_cache_pressure = 50 (Halten Sie Verzeichnisdaten etwas gecached, aber priorisieren Sie Anwendungsspeicher gegenüber VFS-Metadaten, wenn der RAM knapp wird).

Überprüfen Sie vor Änderungen, ob die Datenbank tatsächlich swapped:

free -h
vmstat 1
grep -E 'pswpin|pswpout' /proc/vmstat

Wenn die Swap-In- und Swap-Out-Zähler während Abfragelatenzspitzen steigen, kann das Senken von swappiness helfen. Wenn Swap ungenutzt ist und die Datenbank langsam ist, ist swappiness nicht Ihr Problem. Betrachten Sie stattdessen Abfragepläne, Puffer-Trefferquote, Checkpoints, Festplattenlatenz und Verbindungsdruck.

Szenario 2: Server mit hoher Festplatten-E/A (Caching-Priorität)

Ziel: Maximieren Sie die Festplattenleistung, indem Sie häufig aufgerufene Dateidaten im Page-Cache halten.

vm.swappiness = 80 (Ermöglicht Swapping früher, um RAM für die Erweiterung des Festplatten-Caches freizugeben).
vfs_cache_pressure = 100 (Standardgleichgewicht zwischen Inode- und Page-Cache).

Dies ist das Szenario, in dem Leute am häufigsten überoptimieren. Wenn der Server meistens dieselben Dateien wiederholt liest, ist der Page-Cache wichtig. Aber wenn das System beginnt, aktive Worker-Prozesse auszulagern, um den Cache zu erhalten, können Benutzer eine schlechtere Latenz sehen, selbst wenn der Dateisystem-Cache gesund aussieht. Beobachten Sie die Anwendungsantwortzeit, nicht nur die Cache-Größe.

Szenario 3: Virtualisierungshost oder Allzwecksystem

Ziel: Stabile Leistung über mehrere Arbeitslasten hinweg.

vm.swappiness = 30 (Eine moderate Einstellung, die bevorzugt, aktive VMs/Prozesse etwas länger im RAM zu halten als der Standardwert 60, aber dennoch kontrolliertes Swapping erlaubt).
vfs_cache_pressure = 100 (Standard ist oft ausreichend).

Virtualisierungshosts erfordern besondere Vorsicht, da das Speicherverhalten von Gästen die Optimierung auf Host-Ebene in die Irre führen kann. Ballooning, Überbelegung und Gast-Swap können alle interagieren. Ein Host, der Gast-Speicher stark swapped, kann schmerzhafte Latenz in VMs verursachen, selbst wenn jeder Gast denkt, seine eigene Arbeitslast sei normal.

Ein sichererer Optimierungs-Workflow

Beginnen Sie nicht mit dem Bearbeiten von /etc/sysctl.conf. Beweisen Sie zuerst, dass die Einstellung relevant ist.

Erfassen Sie eine Basislinie während normaler Last:

free -h
vmstat 1 10
cat /proc/sys/vm/swappiness
cat /proc/sys/vm/vfs_cache_pressure

Erfassen Sie dieselben Daten während der langsamen Periode. Fügen Sie Speicher auf Prozessebene hinzu:
```
ps -eo pid,comm,rss,vsz,%mem --sort=-rss | head -20
```
Ändern Sie einen Wert vorübergehend:
```
sudo sysctl vm.swappiness=10
```
Führen Sie die Arbeitslast lange genug aus, um das Verhalten zu beobachten. Achten Sie auf geringere Swap-Aktivität, bessere Anwendungslatenz und keine neuen Dateisystemverlangsamungen.
Machen Sie den Wert nur dauerhaft, nachdem er ein realistisches Testfenster überstanden hat.

Auf Systemen, die /etc/sysctl.d/ verwenden, ist eine kleine dedizierte Datei oft sauberer als das Anhängen an /etc/sysctl.conf:

sudo tee /etc/sysctl.d/90-memory-tuning.conf >/dev/null <<'EOF'
vm.swappiness = 10
vm.vfs_cache_pressure = 100
EOF

sudo sysctl --system

Wenn Ihr Konfigurationsmanagementsystem die sysctl-Einstellungen verwaltet, setzen Sie die Änderung dort ein. Manuelle sysctl-Bearbeitungen auf einem Server sind leicht zu vergessen und schwer zu reproduzieren.

`free -h` lesen, ohne in Panik zu geraten

Eine typische free -h-Ausgabe könnte eine kleine Zahl unter free und eine große Zahl unter buff/cache zeigen. Das ist normal. Linux behält kürzlich verwendete Dateidaten im Speicher, weil ungenutzter RAM niemandem hilft.

Konzentrieren Sie sich auf available, Swap-Nutzung und ob derzeit Swap-Aktivität stattfindet. Ein Server kann Swap von einem vergangenen Speicherspitzenwert zugewiesen haben, aber keinen aktuellen Swap-Churn. Das ist weniger dringend als ein Server, der ständig swapped.

Verwenden Sie:

vmstat 1

Wenn si und so unter normaler Last nahe Null bleiben, treibt Swap nicht aktiv die Latenz in diesem Moment. Wenn sie ungleich Null bleiben, während Anwendungen stocken, ist Speicherdruck ein ernsthafter Verdacht.

Wann diese Einstellungen nicht optimiert werden sollten

Es gibt mehrere Fälle, in denen das Ändern von swappiness oder cache pressure die falsche erste Lösung ist.

Wenn der Server keinen Swap konfiguriert hat, hat vm.swappiness wenig praktische Wirkung. Sie können es dennoch aus Gründen der Richtlinienkonsistenz optimieren, aber es wird den Speicherdruck nicht von selbst lösen.

Wenn Swap nur als winzige Notfallpartition existiert, hat die Einstellung ebenfalls begrenzten Spielraum. Der Kernel kann wählen, wann er Swap verwendet, aber er kann ein paar hundert Megabyte Notfallspeicher nicht in eine echte Speicherebene verwandeln. Konzentrieren Sie sich in diesem Setup auf OOM-Risiko und Dienstgrenzen.

Wenn ein Prozess ein echtes Speicherleck hat, verzögert das Senken von swappiness den Schmerz. Das Leck wird weiter wachsen. Das Neustarten des Dienstes kann die Kapazität vorübergehend wiederherstellen, aber die dauerhafte Lösung ist auf Anwendungsebene: Patchen Sie das Leck, begrenzen Sie den Speicher, reduzieren Sie die Parallelität oder ändern Sie die Arbeitslast.

Wenn die Festplatte aufgrund eines defekten Laufwerks, einer Speicherdrosselung oder eines gesättigten Cloud-Volumes langsam ist, kann die Speicheroptimierung einige Lesevorgänge reduzieren, aber den Speicherfehler nicht beheben. Überprüfen Sie iostat, Kernel-Protokolle, Cloud-Volume-Metriken und SMART/NVMe-Gesundheit.

Wenn der Arbeitssatz größer als der RAM ist, gibt es keinen perfekten sysctl-Wert. Sie benötigen mehr Speicher, weniger Parallelität, kleinere Caches, ein anderes Datenlayout oder eine Arbeitslastaufteilung.

Hinweise zu Containern und Kubernetes

Die Speicheroptimierung wird in Containern kniffliger. Ein Container kann sein cgroup-Speicherlimit erreichen, selbst wenn der Host freien RAM hat. Die swappiness-Einstellung des Hosts ist immer noch wichtig, aber das unmittelbare Symptom kann ein OOM-Kill innerhalb eines Pods oder Containers sein.

Überprüfen Sie cgroup- und Orchestrator-Signale:

dmesg -T | grep -i 'killed process'
docker stats
kubectl describe pod <pod-name>

Für Kubernetes sollte das Ändern von sysctls auf Knotenebene Teil der Knotenpool-Konfiguration sein, nicht einer einmaligen Shell-Sitzung. Denken Sie auch daran, dass einige sysctls namensbasiert und einige auf Knotenebene sind. vm.swappiness und vm.vfs_cache_pressure sind auf typischen Linux-Systemen Einstellungen auf Hostebene, daher wirkt sich ihre Änderung auf jede Arbeitslast auf diesem Knoten aus.

Überwachung und Validierung

Nach dem Anwenden von Änderungen ist eine kontinuierliche Überwachung entscheidend, um die Auswirkung zu validieren. Verwenden Sie Tools wie free, vmstat und Dashboards zur Systemleistungsüberwachung.

Verwenden von vmstat:

Überwachen Sie die Spalten si (swap in) und so (swap out). Ein gesundes System mit niedrigem swappiness sollte unter normaler Last niedrige oder Nullwerte für si und so zeigen.

vmstat 5 10

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\ r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 123456 102400 5123456    0    0     0     5   40   70  1  1 98  0  0

Wenn so-Werte nach dem Reduzieren von swappiness hoch bleiben, benötigt die Arbeitslast wahrscheinlich mehr nutzbaren Speicher oder eine geringere Speichernachfrage. Mehr RAM ist eine Antwort, aber nicht die einzige. Sie können auch die Anzahl der Worker reduzieren, Anwendungs-Caches verkleinern, Datenbankspeicher optimieren, Lecks beheben oder Dienste auf mehrere Hosts verteilen.

Behandeln Sie vm.swappiness und vm.vfs_cache_pressure als Arbeitslastpräferenzen, nicht als universelle Upgrades. Der praktische Weg ist langweilig, aber zuverlässig: Messen Sie das aktuelle Swap- und Rückgewinnungsverhalten, ändern Sie eine Einstellung, testen Sie unter realer Last, und behalten Sie die Änderung nur bei, wenn sich das Anwendungsverhalten verbessert.