vm.vfs_cache_pressure erklärt – Linux Filesystem Cache optimal nutzen

Ich zeige, wie der Kernel-Parameter vm.vfs_cache_pressure den VFS‑Cache gegenüber dem Page Cache gewichtet und welche Werte bei echtem Lastprofil Tempo bringen. Mit klaren Schritten passe ich diesen Schalter an, messe Effekte und nutze so den Filesystem‑Cache optimal.

Zentrale Punkte

Für einen schnellen Start fasse ich die wichtigsten Aspekte zum Tuning des VFS‑Caches zusammen. So behalte ich bei der Wahl des Werts die Wirkung auf Metadaten‑Lookups, IO‑Last und RAM‑Druck im Blick. Die Punkte helfen mir, typische Serverrollen sicher und wiederholbar zu optimieren.

• Wirkprinzip: Steuert, wie entschieden der Kernel Dentries/Inodes im Vergleich zum Page Cache freigibt.
• Standardeinstellung: 100 bedeutet ausgewogene Bereinigung ohne Bevorzugung.
• Niedrige Werte: 50–80 halten Metadaten länger im RAM und beschleunigen Datei‑Lookups.
• Hohe Werte: 120–200 geben VFS‑Caches schneller frei und schaffen Platz für Prozesse.
• Praxis: Schrittweise ändern, messen, dokumentieren – erst dann weiter anpassen.

Ich setze diese Grundsätze konsequent ein, um die richtige Balance zwischen Cache‑Trefferquote und freiem RAM zu finden. Danach passe ich vm.vfs_cache_pressure mit kleinen Schritten an, beobachte Lastspitzen und korrigiere bei Bedarf. So erziele ich stabile Reaktionszeiten ohne unerwartete Speicherengpässe.

Was ist vm.vfs_cache_pressure?

Der Parameter steuert, wie hart der Kernel den VFS‑Cache im Vergleich zu anderen Speichern räumt, sobald RAM knapp wird. Im VFS‑Cache landen Dentries und Inodes, also Verzeichnis‑Einträge und Dateimetadaten, die Datei‑Lookups spürbar beschleunigen. Ein Wert von 100 behandelt VFS‑Cache und Page Cache gleich, während niedrigere Werte Metadaten bevorzugt im RAM halten. Höhere Werte veranlassen den Kernel, VFS‑Einträge früher zu verwerfen und Speicher schneller freizugeben. Ich nutze diesen Hebel gezielt, um Metadaten‑Treffer bei Web‑, Datei‑ und CMS‑Workloads hoch zu halten, ohne Prozesse zu verdrängen. So kontrolliere ich die Balance zwischen Lookup‑Tempo und freiem Arbeitsspeicher sehr direkt.

Wie funktioniert der VFS‑Cache im Detail?

Das Virtual Filesystem bildet eine gemeinsame Schicht für ext4, XFS, Btrfs und Co. und speichert Dentries und Inodes im RAM, damit Directory‑Scans und wiederkehrende Zugriffe flott bleiben. Der Page Cache hält hingegen die eigentlichen Dateiblöcke; beide Caches ergänzen sich, konkurrieren aber unter Druck um Speicher. Je mehr kleine Dateien und häufige Wiederholungszugriffe anfallen, desto stärker profitiert die Anwendung von einer hohen Metadaten‑Trefferquote. Genau hier wirkt vm.vfs_cache_pressure: Ich beeinflusse, ob Linux diese Metadaten behält oder rasch verdrängt. Für tiefergehende Page‑Cache‑Aspekte setze ich ergänzend den kompakten Page‑Cache Performance Booster als Hintergrundwissen ein, damit ich VFS‑ und Page Cache im Kontext bewerte.

Standardwert und typische Wertebereiche

Auf den meisten Systemen steht der Wert auf 100 und bildet damit eine ausgewogene Basis für erste Tests. Senke ich den Wert, bevorzuge ich Metadaten und stabilisiere schnelle Lookups, was vor allem bei vielen kleinen Dateien greift. Erhöhe ich den Wert, dann baut Linux VFS‑Einträge schneller ab und schafft mehr Puffer für Applikationen oder den Page Cache. Extremwerte wie 0 oder Werte über 500 fasse ich nur sehr vorsichtig an, da sie starkes Verhalten auslösen und Seiteneffekte provozieren können. Im Alltag starte ich bei 100, taste mich in Schritten von 20–40 Punkten vor und messe die Wirkung auf IO‑Latenz und Antwortzeiten.

Wert	Bedeutung	Wann einsetzen	Risiko/Hinweis
< 100 (z. B. 50–80)	VFS‑Cache bleibt länger im RAM	Viele kleine Dateien, häufige Lookups	Mehr RAM‑Bindung an Metadaten
100	Ausgewogene Bereinigung	Solider Startwert für Messungen	Guter Baseline‑Wert
> 100 (z. B. 120–200)	VFS‑Cache wird aggressiver freigegeben	RAM knapp, Datenbanken mit eigenem Cache	Mögliche Lookup‑Latenz
Extrem (0, > 500)	Gravierende Verschiebungen	Spezialfälle, kurz testen	Gefahr für Stabilität und Performance

Mit diesem Raster erkenne ich schnell, welche Richtung passt, ohne mich zu verrennen. Ich vermeide Sprünge in großen Stufen und protokolliere jede Änderung ausführlich. So bleibt der Weg zurück stets klar und ich halte den Vergleich zu vorherigen Messpunkten sauber.

Rolle bei der Speicherbereinigung

Unter Druck muss der Kernel RAM freigeben, und genau hier definiert vm.vfs_cache_pressure die Gewichtung zwischen VFS‑Cache, Page Cache und Prozessspeicher. Niedrige Werte halten Verzeichnis‑ und Inode‑Einträge länger im Speicher, was Directory‑Aufrufe und wiederholte Dateiöffnungen zügig bedient. Hohe Werte geben früher frei und stellen mehr Platz für Prozesse oder den Page Cache bereit, was bei knappem RAM hilfreich sein kann. Ich beobachte dabei gezielt IO‑Latenzen, da ein zu leerer Metadaten‑Cache die Dateisuche bremst. Für das Zusammenspiel mit Page‑Cache‑Räumstrategien liefert mir dieser Einblick zu Page‑Cache Eviction wertvolle Praxisbezüge, damit ich Entscheidungen faktenbasiert treffe.

Messmethodik: VFS‑Cache transparent machen

Bevor ich ändere, mache ich sichtbar, wo Speicher steckt und was verdrängt wird. So erkenne ich, ob Metadaten wirklich der Engpass sind – oder ob Page Cache, Prozesse oder Dirty Pages dominieren.

• /proc/meminfo: Ich prüfe InodeCache, Cached, Buffers, SReclaimable und SUnreclaim, um Anteil und Rückgewinnbarkeit einzuschätzen.
• slabtop: Live‑Sicht auf Slabs, insbesondere dentry, inode_cache, ext4_inode_cache, xfs_inode. So sehe ich, ob Dentries/ Inodes wachsen und schrumpfen.
• IO‑Pfad: Mit vmstat/iostat beobachte ich Leselatenzen und ob Plattenzugriffe bei Lookups anziehen.

# Schneller Überblick
grep -E 'InodeCache|SReclaimable|SUnreclaim|Cached|Buffers' /proc/meminfo

# Slab-Verteilung (sortiert nach Größe)
sudo slabtop -s c

# Nur dentry/inode-ähnliche Slabs herausfiltern
grep -Ei 'dentry|inode' /proc/slabinfo | sort -k3 -nr | head

# IO- und Speichertrends im Sekundentakt
vmstat 1
iostat -x 1

Die Interpretation halte ich klar: Wächst SReclaimable zusammen mit dentry/inode‑Slabs und steigen gleich­zeitig die IO‑Latenzen nicht, bestätigt das einen wirksamen Metadaten‑Cache. Fallen diese Werte häufig auf Null und schnellen Latenzen bei Directory‑Zugriffen hoch, ist vm.vfs_cache_pressure vermutlich zu aggressiv.

Praxis: Aktuellen Wert auslesen und ändern

Die Kontrolle gelingt auf der Kommandozeile in Sekunden und ohne Neustart. Den Ist‑Wert lese ich aus und schreibe Testwerte zunächst temporär, damit ich Rücksprünge im Testfenster sofort umsetzen kann. Für produktive Anpassungen setze ich Einträge in /etc/sysctl.conf oder einer Datei in /etc/sysctl.d/, lade sie neu und halte die Änderung in meiner Dokumentation fest. Ich teste jede Stufe unter realistischer Last, nicht nur im Leerlauf, damit Effekte sichtbar werden. So sichere ich saubere Vorher‑Nachher‑Vergleiche und bewerte die Änderung anhand messbarer Kennzahlen.

# Aktuellen Wert prüfen
cat /proc/sys/vm/vfs_cache_pressure
# oder
sysctl vm.vfs_cache_pressure

# Temporär testen (bis zum Neustart)
sudo sysctl -w vm.vfs_cache_pressure=60
# alternativ
echo 60 | sudo tee /proc/sys/vm/vfs_cache_pressure

# Dauerhaft setzen
echo "vm.vfs_cache_pressure = 60" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

linux cache tuning: sinnvolle Szenarien

In Hosting‑Plattformen mit vielen statischen Assets, Dateiablagen oder Applikationen mit eigenem Puffer lohnt eine gezielte Gewichtung des VFS‑Caches. Webserver mit zahlreichen kleinen Dateien profitieren stark von niedrigeren Werten, weil Lookups seltener auf SSD/HDD treffen. Fileserver mit gemischten Dateigrößen können moderat abgesenkte Werte nutzen, wenn genug RAM vorhanden ist. Datenbankserver mit hohem RAM‑Druck und großem DB‑Cache bevorzugen höhere Werte, damit Prozesse Raum bekommen. Ich bewerte diese Muster jeweils mit Monitoringdaten, damit die Einstellungen zum tatsächlichen Zugriffsmix passen.

Webserver mit vielen statischen Dateien

Für CSS, JS und Bilder halte ich die Metadaten gern länger im Cache. Werte zwischen 50 und 80 haben sich dabei oft bewährt, weil erneute Dateiöffnungen schneller laufen. Kritisch prüfe ich IO‑Spitzen während Traffic‑Bursts und vergleiche Antwortzeiten vor und nach der Änderung. Bleiben die Latenzen stabil und sinken 404‑Lookup‑Kosten, passt die Richtung. Ich behalte die RAM‑Belegung im Blick, damit Prozesse trotz stärkerem Metadaten‑Cache ausreichend Platz haben.

Fileserver oder NAS‑Systeme

Viele Nutzerzugriffe und Verzeichniswechsel profitieren von niedrigeren bis ausgewogenen Werten. Liegt genug RAM vor, setze ich eher Richtung 50–80; bei knapperem Speicher bleibe ich näher an 100. Ich prüfe, ob Directory‑Auflistungen flüssig bleiben und ob Snapshots/Backups die Caches nicht zu stark verdrängen. Nimmt die IO‑Latenz bei Peaks zu, korrigiere ich behutsam nach oben. So wahre ich die Balance zwischen Komfort und freiem Arbeitsspeicher.

Datenbankserver und speicherarme Systeme

Datenbanken pflegen einen eigenen Buffer‑Cache, daher gebe ich dem Prozessspeicher meist Vorrang. Werte zwischen 120 und 200 setzen das Signal, VFS‑Caches eher zu leeren und RAM freizumachen. Ich achte dabei auf Query‑Latenzen und Page‑Fault‑Muster der Applikation. Wird die DB gebremst, weil das System anfängt zu swappen, ziehe ich den Wert leicht an und reduziere nebenbei vm.swappiness. Dieser Ansatz verhindert, dass Metadaten unnötig Platz belegen, den die DB besser nutzt.

Workload‑Beispiele und Richtwerte

Ich starte mit 100, reduziere in 20er‑Schritten für webnahe Workloads und erhöhe in 20er‑Schritten für speicherhungrige Prozesse. Jede Stufe teste ich mindestens über eine Peak‑Phase, damit ich Effekte auf Latenzen, Cache‑Treffer und Swap‑Aktivität erkenne. Wer tiefer einsteigen möchte, findet im kompakten Page‑Cache Performance Booster ergänzende Hintergründe zu Dateicache‑Strategien, die ich parallel berücksichtige. Treffen Messwerte und Zielbild aufeinander, friere ich die Konfiguration ein und dokumentiere die Kennzahlen. So bleibt die Optimierung reproduzierbar und ich kann später zügig nachjustieren.

Risiken und Stolperfallen

Setze ich den Wert zu niedrig, kann der Kernel VFS‑Einträge kaum frei machen, was bei Spitzen zu OOM‑Risiken führt. Hebe ich ihn zu stark an, steigt die Latenz bei Datei‑Lookups und Verzeichniswechseln, weil Metadaten erneut geladen werden müssen. Ohne Tests unter echter Last drohen falsche Schlüsse aus ruhigen Zeitfenstern. Abrupte Sprünge erschweren die Bewertung, daher gehe ich schrittweise vor. Jede Änderung notiere ich mit Zeitpunkt, Lastprofil und Messwerten, damit Ursachen klar bleiben.

Monitoring und Messgrößen

Ob sich eine Anpassung lohnt, zeigen harte Metriken. Ich beobachte RAM‑Nutzung, Aufteilung zwischen Caches und Prozessen, IO‑Latenzen und Swap‑Aktivität. Zusätzlich werte ich Cache‑Trefferquoten und Page‑Fault‑Trends aus, um Seiteneffekte schnell zu erkennen. Gerade bei vielen kleinen Dateien fallen Verbesserungen in der Time‑to‑First‑Byte auf. Bleibt die IO‑Latenz niedrig und verringert sich das Swapping, bestätigt das den Kurs.

Tuning‑Playbook: Von der Hypothese zur verlässlichen Einstellung

Struktur vermeidet Blindflüge. Ich gehe in einem festen Ablauf vor, damit Ergebnisse belastbar werden und Teamkollegen die Schritte nachvollziehen können.

1. Baseline erfassen: vm.vfs_cache_pressure=100, 24–72 h realistische Last. Kennzahlen sichern (Latenzen: Median/95./99., IO‑Wartezeit, CPU‑Steal, Swap‑Aktivität, Inode/Dentry‑Größe).
2. Hypothese formulieren: „Viele kleine Dateien, Lookups sind teuer – niedrigere Werte beschleunigen“ oder „RAM knapp – höhere Werte halten Prozesse frei“.
3. Schrittweise ändern: ±20 bis ±40 Punkte. Pro Stufe mindestens eine Peak‑Phase messen.
4. Vergleichen: Ich prüfe, ob die SLOs (z. B. 95.‑Perzentil) zuverlässig besser werden, ohne mehr Swap oder OOM‑Events.
5. Rollback‑Kriterium: Steigen 95./99.‑Latenzen, wachsen IO‑Wartezeiten oder häufen sich Cache‑Misses, gehe ich einen Schritt zurück.
6. Freeze & Dokumentation: Finalen Wert, Datum, Lastfenster und Kennzahlen festhalten.

# Kurztest für kontrollierte Messfenster (nur Maintenance!)
# Vorher: Kennzahlen snapshotten
date; free -h; grep -E 'InodeCache|Cached' /proc/meminfo; vmstat 1 5

sudo sysctl -w vm.vfs_cache_pressure=80
# Lasttest/Peak abwarten, dann erneut Metriken erfassen und vergleichen

Dateisysteme und Mount‑Optionen: Kontext zählt

Die Wirkung von vm.vfs_cache_pressure hängt auch vom Dateisystem und den Mount‑Optionen ab. Ich bewerte diese Faktoren mit:

• relatime/noatime: Verhindert häufige atime‑Writes. noatime senkt IO‑Druck bei vielen Reads, was Metadaten‑Vorteile stärker sichtbar macht.
• lazytime: Verzögert Metadaten‑Updates im RAM; das glättet Peaks, interagiert aber mit Flush‑Zeitpunkten.
• ext4 vs. XFS vs. Btrfs: Unterschiedliche Inode‑Strukturen und Shrinker‑Verhalten. Ich messe stets auf dem Ziel‑FS, statt Annahmen zu übertragen.
• NFS/Netz‑FS: Attribute‑Caching und Invalidation können den VFS‑Nutzen begrenzen. Aggressive Freigabe (hohe Werte) treibt dann Remote‑Lookups hoch.
• OverlayFS/FUSE: Viele kleine Metadaten‑Vorgänge profitieren stark vom VFS‑Cache; ich halte die Werte eher moderat bis niedrig, sofern RAM vorhanden ist.

Container‑ und Cgroup‑Aspekte

In Container‑Umgebungen behalte ich im Hinterkopf: vm.vfs_cache_pressure ist ein hostweiter Schalter. Änderungen betreffen alle Pods/Container auf dem Knoten. Ich gehe deshalb konservativ vor und koordiniere Tuning auf Node‑Ebene.

• Speichergrenzen: Memory‑Cgroups begrenzen Prozess‑ und Page‑Cache; Slab‑Speicher kann anteilig angerechnet werden. Ich beobachte Pod‑OOMs und Node‑Pressure‑Events im Zusammenhang.
• Workload‑Mix: Knoten mit DB‑Pods und Web‑Frontends zugleich bekommen keine Extremwerte. Bei Bedarf trenne ich Rollen auf verschiedene Nodes.
• Rollout: Erst Canaries (ein Node), dann gestaffelt ausrollen. Änderungen dokumentiere ich in der Node‑Baseline (sysctl.d) und vermerke die betroffenen Deployments.

Sonderfälle aus der Praxis

Einige Muster lassen sich gezielt adressieren, wenn ich die Ursachen kenne:

• CI/Build‑Jobs: Viele kurze Dateizugriffe und Directory‑Scans profitieren von niedrigeren Werten. Ich erhöhe sie nach Jobende wieder, falls Knoten gemischt genutzt werden.
• Backup/Scan‑Fenster: Lange Verzeichnisläufe verdrängen Caches. Temporär kann ein höherer Wert (z. B. 180) während des Backups verhindern, dass Dentries/Inodes den RAM füllen – danach stelle ich zurück.
• Negative Dentries: Nicht vorhandene Dateien (404) werden ebenfalls gecacht. Web‑Workloads mit häufigen Fehlzugriffen gewinnen messbar, wenn der VFS‑Cache nicht zu aggressiv geleert wird.
• Streaming/Sequential I/O: Hier dominiert der Page Cache; zu niedrige Werte bringen wenig und binden unnötig RAM. Ich bleibe nahe 100 oder etwas darüber.

# Beispiel: während eines Vollbackups etwas aggressiver werden
sudo sysctl -w vm.vfs_cache_pressure=180
# Nach dem Backup wieder auf den zuvor ermittelten Optimalwert zurück
sudo sysctl -w vm.vfs_cache_pressure=60

Automatisierung und Governance

Nach erfolgreichen Tests baue ich die Einstellung in meine Standard‑Builds ein. Wichtig ist, dass Teams wissen, warum ein Wert gewählt wurde und wann er zu prüfen ist (z. B. nach Versions‑ oder Workload‑Wechseln).

• Konfigurationsmanagement: Ich pflege pro Rolle (Web, DB, Fileserver) definierte Defaults in /etc/sysctl.d/ und verteile sie zentral.
• Drift‑Kontrolle: Regelmäßige Audits prüfen, ob Live‑Werte und Repository übereinstimmen.
• Runbooks: Ich dokumentiere Messschritte, Grenzwerte für Rollback und Notfall‑Prozeduren (z. B. Rücksetzen auf 100).

# Rolle: Webserver (Beispiel)
cat <<'EOF' | sudo tee /etc/sysctl.d/50-web-vfs.conf
vm.vfs_cache_pressure = 60
EOF
sudo sysctl --system

vm.vfs_cache_pressure und weitere Kernel‑Parameter

Ein gutes Ergebnis entsteht erst im Zusammenspiel mit vm.swappiness und den Dirty‑Page‑Schwellwerten. Eine niedrigere Swappiness (z. B. 10–20) hält Prozesse eher im RAM und vermeidet unnötige Auslagerung. Mit vm.dirty_background_ratio und vm.dirty_ratio reguliere ich, wie früh das System geänderte Seiten wegschreibt, damit Schreibpeaks nicht alles blockieren. Ich richte diese Werte so aus, dass Metadaten‑Lookups schnell bleiben und Schreibvorgänge planbar ablaufen. Einen prägnanten Überblick zum Zusammenspiel von Dateicaches nutze ich hier: Filesystem‑Caching Überblick.

Empfehlungen für Hosting‑Umgebungen und WordPress

Viele Themes, Plugins und Medien erzeugen zahllose kleine Dateien, weshalb ein kräftiger VFS‑Cache spürbar hilft. Ich starte mit 100, senke bei ausreichendem RAM auf 80, später 60, und prüfe Antwortzeiten, 95.‑Perzentil der Latenzen und CPU‑Steal. Bleibt der Speicher komfortabel, teste ich 50 und validiere erneut im Abend‑Peak oder während Kampagnen. Fallen Latenzen, ohne dass Swap oder OOM‑Killer anschlagen, sichere ich die Einstellung dauerhaft. Parallel halte ich den Page‑Cache im Blick, damit sich beide Caches sinnvoll ergänzen.

Zusammenfassung

Mit vm.vfs_cache_pressure steuere ich die Balance zwischen schnellen Metadaten‑Lookups und freiem RAM sehr gezielt. Für webnahe Workloads senke ich den Wert moderat, für speicherhungrige Applikationen hebe ich ihn an. Jede Änderung belege ich mit Messwerten zu IO‑Latenzen, Cache‑Treffern und Swap‑Aktivität. In Kombination mit vm.swappiness und den Dirty‑Parametern erreiche ich eine ruhige Speicherbewirtschaftung. So nutze ich den Linux Filesystem Cache effizient und halte Reaktionszeiten unter Last zuverlässig niedrig.