Ga naar de inhoud 
Ik laat zien hoe de kernelparameter vm.vfs_cache_druk hoe de VFS-cache ten opzichte van de paginacache wordt gewogen en welke waarden bij een reëel belastingsprofiel voor meer snelheid zorgen. Met duidelijke stappen pas ik deze instelling aan, meet ik de effecten en maak ik zo gebruik van de Bestandssysteemcache optimaal.
Centrale punten
Om snel aan de slag te kunnen, vat ik de belangrijkste aspecten van het tunen van de VFS-caches samen. Zo houd ik bij het kiezen van de waarde rekening met het effect op metadata-lookups, de I/O-belasting en de druk op het RAM-geheugen. Deze punten helpen me om typische serverrollen op een betrouwbare en herhaalbare manier te optimaliseren.
- Werkingsprincipe: Bepaalt hoe resoluut de kernel Dentries/inodes vrijgeeft in vergelijking met de paginacache.
- Standaardinstelling: 100 betekent een evenwichtige correctie zonder voorkeursbehandeling.
- Lage waarden: 50–80 zorgen ervoor dat metadata langer in het RAM-geheugen blijven en versnellen het opzoeken van bestanden.
- Hoge waarden: 120–200 maken VFS-caches sneller vrij en maken ruimte vrij voor processen.
- Praktijk: Stapsgewijs aanpassen, meten, documenteren – pas daarna verder aanpassen.
Ik pas deze principes consequent toe om de juiste balans te vinden tussen Cache-hit rate en beschikbare RAM. Vervolgens pas ik vm.vfs_cache_pressure in kleine stapjes aan, houd ik pieken in de belasting in de gaten en corrigeer ik indien nodig. Zo zorg ik voor stabiele responstijden zonder onverwachte geheugenbeperkingen.
Wat is vm.vfs_cache_pressure?
Deze parameter bepaalt hoe streng de kernel de VFS-cache in vergelijking met andere opslagmedia ruimt het op zodra het RAM-geheugen schaars wordt. In de VFS-cache komen dentries en inodes terecht, dat wil zeggen mapvermeldingen en bestandsmetadata, die het opzoeken van bestanden merkbaar versnellen. Een waarde van 100 behandelt de VFS-cache en de paginacache op dezelfde manier, terwijl lagere waarden er de voorkeur aan geven metadata in het RAM te houden. Hogere waarden zorgen ervoor dat de kernel VFS-vermeldingen eerder verwijdert en geheugen sneller vrijmaakt. Ik gebruik deze instelling doelgericht om het aantal metadata-treffers bij web-, bestands- en CMS-workloads hoog te houden, zonder processen te verdringen. Zo regel ik de balans tussen Zoeksnelheid en het beschikbare werkgeheugen op een zeer directe manier.
Hoe werkt de VFS-cache precies?
Het Virtual Filesystem vormt een gemeenschappelijke laag voor ext4, XFS, Btrfs en dergelijke en slaat Dentries en inodes in het RAM, zodat het scannen van mappen en herhaalde toegangen vlot blijven verlopen. De paginacache bevat daarentegen de eigenlijke bestandsblokken; beide caches vullen elkaar aan, maar concurreren onder druk om geheugen. Hoe meer kleine bestanden en frequente herhaalde toegangen er zijn, hoe meer de toepassing profiteert van een hoog metagegevens-hitpercentage. Precies hier komt vm.vfs_cache_pressure om de hoek kijken: ik bepaal of Linux deze metadata behoudt of snel vervangt. Voor meer diepgaande aspecten van de paginacache gebruik ik aanvullend het compacte Page-Cache Performance Booster als achtergrondkennis, zodat ik VFS en paginacache in de juiste context kan beoordelen.
Standaardwaarde en typische waardenbereiken
Op de meeste systemen is de waarde ingesteld op 100 en vormt daarmee een evenwichtige basis voor de eerste tests. Als ik de waarde verlaag, geef ik de voorkeur aan metadata en zorg ik voor snellere opzoekingen, wat vooral bij veel kleine bestanden van pas komt. Als ik de waarde verhoog, breekt Linux VFS-vermeldingen sneller af en creëert het meer bufferruimte voor applicaties of de paginacache. Extreme waarden zoals 0 of waarden boven de 500 behandel ik slechts met grote voorzichtigheid, omdat ze drastische gedragsveranderingen kunnen veroorzaken en bijwerkingen kunnen uitlokken. In de dagelijkse praktijk begin ik bij 100, ga ik stap voor stap verder in stappen van 20–40 punten en meet ik het effect op IO-latentie en responstijden.
| Waarde | Dat betekent | Wanneer gebruiken? | Risico/Opmerking |
|---|---|---|---|
| < 100 (bijv. 50–80) | De VFS-cache blijft langer in het RAM-geheugen | Veel kleine bestanden, veelvuldige opzoekingen | Meer RAM-toewijzing aan Metagegevens |
| 100 | Evenwichtige aanpassing | Een betrouwbare startwaarde voor metingen | Goed Basislijn-waarde |
| > 100 (bijv. 120–200) | VFS-cache wordt agressiever vrijgegeven | Weinig RAM, databases met eigen cache | Mogelijke opzoekvertraging |
| Extreem (0, > 500) | Ingrijpende verschuivingen | Bijzondere gevallen, kort testen | Gevaar voor de stabiliteit en Prestaties |
Met dit schema zie ik snel welke richting de juiste is, zonder me te verliezen in details. Ik vermijd grote sprongen en leg elke wijziging gedetailleerd vast. Zo blijft het afgelegde traject altijd duidelijk en houd ik de vergelijking met eerdere meetpunten nauwkeurig bij.
Rol bij het opschonen van het geheugen
Onder druk moet de kernel RAM vrijgeven, en juist hier bepaalt vm.vfs_cache_pressure de afweging tussen VFS-cache, paginacache en procesgeheugen. Lage waarden houden directory- en inode-vermeldingen langer in het geheugen, waardoor directory-aanroepen en herhaaldelijk openen van bestanden snel worden afgehandeld. Hoge waarden geven het geheugen eerder vrij en maken meer ruimte beschikbaar voor processen of de paginacache, wat nuttig kan zijn bij beperkte RAM. Ik let daarbij specifiek op IO-latenties, omdat een te lege metadatacache het zoeken naar bestanden vertraagt. Voor de interactie met strategieën voor het vrijmaken van de paginacache geeft dit mij inzicht in Verwijdering uit de paginacache waardevolle praktijkgerichte inzichten, zodat ik beslissingen op basis van feiten kan nemen.
Meetmethode: de VFS-cache transparant maken
Voordat ik iets verander, maak ik het zichtbaar, waarbij geheugen zit en wat wordt verdrongen. Zo kan ik vaststellen of metadata echt het knelpunt is – of dat de paginacache, processen of ‘dirty pages’ de overhand hebben.
- /proc/meminfo: Ik controleer InodeCache, Cached, Buffers, SReclaimable en SUnreclaim om het aandeel en de terugwinbaarheid in te schatten.
- plaattop: Live-overzicht van slabs, met name dentry, inode_cache, ext4_inode_cache en xfs_inode. Zo kan ik zien of dentries/inodes groter of kleiner worden.
- IO-pad: Met vmstat/iostat houd ik de leestijden in de gaten en kijk ik of het aantal schijftoegangen toeneemt bij lookups.
# Snel overzicht
grep -E 'InodeCache|SReclaimable|SUnreclaim|Cached|Buffers' /proc/meminfo
# Slab-verdeling (gesorteerd op grootte)
sudo slabtop -s c
# Alleen dentry/inode-achtige slabs eruit filteren
grep -Ei 'dentry|inode' /proc/slabinfo | sort -k3 -nr | head
# IO- en geheugentrends per seconde
vmstat 1
iostat -x 1
Ik vind de interpretatie duidelijk: als SReclaimable samen met dentry/inode-slabs groeit en tegelijkertijd de IO-latenties toenemen niet, dit wijst op een effectieve metadata-cache. Als deze waarden vaak tot nul dalen en snel weer stijgen bij directory-toegangen, is vm.vfs_cache_pressure waarschijnlijk te agressief ingesteld.
Praktijk: de huidige waarde uitlezen en wijzigen
De controle kan via de opdrachtregel binnen enkele seconden worden uitgevoerd, zonder Herstart. Ik lees de actuele waarde uit en schrijf testwaarden eerst tijdelijk op, zodat ik terugsprongen in het testvenster direct kan doorvoeren. Voor productieve aanpassingen voeg ik vermeldingen toe aan /etc/sysctl.conf of een bestand in /etc/sysctl.d/, laad ik deze opnieuw en leg ik de wijziging vast in mijn documentatie. Ik test elke stap onder realistische belasting, niet alleen in ruststand, zodat effecten zichtbaar worden. Zo zorg ik voor duidelijke voor-en-na-vergelijkingen en beoordeel ik de wijziging aan de hand van meetbare kengetallen.
# Huidige waarde controleren
cat /proc/sys/vm/vfs_cache_pressure
# of
sysctl vm.vfs_cache_pressure
# Tijdelijk testen (tot de volgende herstart)
sudo sysctl -w vm.vfs_cache_pressure=60
# alternatief
echo 60 | sudo tee /proc/sys/vm/vfs_cache_pressure
# Permanent instellen
echo "vm.vfs_cache_pressure = 60" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
Linux-cache-optimalisatie: zinvolle scenario’s
Bij hostingplatforms met veel statische bestanden, bestandsopslagplaatsen of applicaties met een eigen buffer loont het de moeite om gericht weging van de VFS-cache. Webservers met veel kleine bestanden hebben veel baat bij lagere waarden, omdat lookups minder vaak op SSD/HDD terechtkomen. Bestandsservers met gemengde bestandsgroottes kunnen gebruikmaken van matig verlaagde waarden, mits er voldoende RAM beschikbaar is. Databaseservers met een hoge RAM-belasting en een grote DB-cache geven de voorkeur aan hogere waarden, zodat processen voldoende ruimte krijgen. Ik evalueer deze patronen telkens aan de hand van monitoringgegevens, zodat de instellingen aansluiten bij de daadwerkelijke mix van toegangsverzoeken.
Webserver met veel statische bestanden
Voor CSS, JS en afbeeldingen bewaar ik de metagegevens graag wat langer in de Cache. Waarden tussen 50 en 80 hebben zich daarbij vaak bewezen, omdat het opnieuw openen van bestanden sneller verloopt. Ik controleer kritisch de IO-pieken tijdens verkeerspieken en vergelijk de responstijden voor en na de wijziging. Als de latenties stabiel blijven en de 404-lookup-kosten dalen, zitten we op de goede weg. Ik houd het RAM-gebruik in de gaten, zodat processen ondanks een grotere metadata-cache voldoende ruimte hebben.
Bestandsservers of NAS-systemen
Veel gebruikersbezoeken en mapwisselingen profiteren van lagere tot evenwichtige waarden. Als er voldoende RAM beschikbaar is, neig ik eerder naar 50–80; bij minder geheugen blijf ik dichter bij 100. Ik controleer of het weergeven van mappen soepel verloopt en of snapshots/back-ups de caches niet te veel verdringen. Als de IO-latentie tijdens pieken toeneemt, pas ik de waarde voorzichtig naar boven aan. Zo behoud ik het evenwicht tussen gebruiksgemak en vrij werkgeheugen.
Databaseservers en systemen met weinig geheugen
Databases hebben een eigen buffer-cache, daarom geef ik de Procesgeheugen meestal voorrang. Waarden tussen 120 en 200 geven aan dat de VFS-caches eerder moeten worden leeggemaakt om RAM vrij te maken. Daarbij let ik op de query-latenties en de page-fault-patronen van de applicatie. Als de database wordt afgeremd omdat het systeem begint te swappen, verhoog ik de waarde iets en verlaag ik tegelijkertijd vm.swappiness. Deze aanpak voorkomt dat metadata onnodig ruimte in beslag neemt die de database beter kan gebruiken.
Voorbeelden van werkbelasting en richtwaarden
Ik begin met 100 en verlaag het in stappen van 20 voor webgerichte Werklasten en verhoog ik in stappen van 20 voor processen die veel geheugen verbruiken. Ik test elk niveau gedurende ten minste één piekfase, zodat ik de effecten op latenties, cache-hits en swap-activiteit kan vaststellen. Wie zich hier verder in wil verdiepen, vindt in het beknopte Page-Cache Performance Booster aanvullende achtergrondinformatie over bestandscache-strategieën, waarmee ik tegelijkertijd rekening houd. Als de gemeten waarden en het streefbeeld overeenkomen, leg ik de configuratie vast en documenteer ik de kengetallen. Zo blijft de optimalisatie reproduceerbaar en kan ik later snel bijsturen.
Risico's en valkuilen
Als ik de waarde te laag instel, kan de kernel VFS-vermeldingen nauwelijks vrijmaken, wat bij pieken tot OOM‑risico’s met zich meebrengt. Als ik deze te hoog instel, neemt de latentie bij het opzoeken van bestanden en het wisselen van mappen toe, omdat metadata opnieuw moet worden geladen. Zonder tests onder reële belasting bestaat het risico dat er verkeerde conclusies worden getrokken op basis van rustige periodes. Abrupte sprongen bemoeilijken de beoordeling, daarom ga ik stapsgewijs te werk. Ik noteer elke wijziging met het tijdstip, het belastingprofiel en de meetwaarden, zodat de oorzaken duidelijk blijven.
Monitoring en meetgrootheden
Of een aanpassing de moeite waard is, blijkt uit harde Metriek. Ik houd het RAM-gebruik, de verdeling tussen caches en processen, IO-latenties en swap-activiteit in de gaten. Daarnaast analyseer ik cache-hitpercentages en trends in page-fouts om bijwerkingen snel te herkennen. Vooral bij veel kleine bestanden vallen verbeteringen in de ‘time-to-first-byte’ op. Als de IO-latentie laag blijft en het swappen afneemt, bevestigt dat de koers.
Tuning-Playbook: van hypothese tot betrouwbare instelling
Een gestructureerde aanpak voorkomt dat we in het duister tasten. Ik volg een vaste werkwijze, zodat de resultaten betrouwbaar zijn en mijn teamgenoten de stappen kunnen volgen.
- Uitgangssituatie vastleggen: vm.vfs_cache_pressure=100, 24–72 uur realistische belasting. Kerncijfers vastleggen (latenties: mediaan/95e/99e percentiel, IO-wachttijd, CPU-steal, swap-activiteit, inode/dentry-grootte).
- Een hypothese formuleren: „Veel kleine bestanden, lookups zijn duur – lagere waarden versnellen het proces“ of „Weinig RAM – hogere waarden houden processen vrij“.
- Stapsgewijs wijzigen: ±20 tot ±40 punten. Meet per niveau ten minste één piekfase.
- Vergelijken: Ik ga na of de SLO's (bijvoorbeeld het 95e percentiel) betrouwbaar verbeteren, zonder meer swap- of OOM-gebeurtenissen.
- Rollback-criterium: Als de 95e/99e-latentie toeneemt, de IO-wachttijden langer worden of er steeds vaker cache-misses optreden, doe ik een stap terug.
- Freeze & documentatie: De eindwaarde, datum, belastingsvenster en kengetallen vastleggen.
# Korte test voor gecontroleerde meetvensters (alleen onderhoud!)
# Vooraf: momentopname van kengetallen maken
date; free -h; grep -E 'InodeCache|Cached' /proc/meminfo; vmstat 1 5
sudo sysctl -w vm.vfs_cache_pressure=80
# Belastingstest/piek afwachten, daarna opnieuw statistieken vastleggen en vergelijken
Bestandssystemen en mount-opties: de context is belangrijk
Het effect van vm.vfs_cache_pressure hangt ook af van het bestandssysteem en de mount-opties. Ik beoordeel deze factoren aan de hand van:
- relatijd/geen-tijd: Voorkomt veelvuldige atime-schrijfbewerkingen. noatime vermindert de IO-belasting bij veel leesbewerkingen, waardoor de voordelen van metadata beter zichtbaar worden.
- luiheid: Stelt het bijwerken van metadata in het RAM uit; dit zorgt ervoor dat pieken worden afgevlakt, maar heeft invloed op de tijdstippen waarop het geheugen wordt leeggemaakt.
- ext4 versus XFS versus Btrfs: Verschillende inode-structuren en het gedrag van de shrinker. Ik meet altijd op de doel-FS, in plaats van aannames over te nemen.
- NFS/Netwerk-FS: Het cachen en ongeldig maken van attributen kan de voordelen van VFS beperken. Agressieve vrijgave (hoge waarden) leidt dan tot een toename van het aantal opzoekingen op afstand.
- OverlayFS/FUSE: Veel kleine metadataprocessen hebben veel baat bij de VFS-cache; ik houd de waarden eerder gematigd tot laag, mits er voldoende RAM beschikbaar is.
Aspecten met betrekking tot containers en cgroups
In containeromgevingen houd ik het volgende in gedachten: vm.vfs_cache_pressure is een op het hele hostniveau Schakelaar. De wijzigingen hebben betrekking op alle Pods/containers op het knooppunt. Ik hanteer daarom een voorzichtige aanpak en coördineer de afstemming op knooppuntniveau.
- Opslaglimieten: Memory-cgroups beperken het proces- en paginacachegeheugen; slab-geheugen kan hieraan worden toegerekend naar rato. Ik constateer dat er een verband bestaat tussen pod-OOM’s en node-pressure-gebeurtenissen.
- Workload-mix: Knooppunten die zowel DB-pods als web-frontends bevatten, krijgen geen extreme waarden. Indien nodig verdeel ik de rollen over verschillende knooppunten.
- Uitrol: Eerst Canaries (één node), daarna gefaseerd uitrollen. Ik documenteer de wijzigingen in de node-baseline (sysctl.d) en noteer de betrokken deployments.
Speciale gevallen uit de praktijk
Sommige patronen kunnen gericht worden aangepakt als ik de oorzaken ken:
- CI/Build-taken: Bij veel korte bestandstoegangen en directory-scans is het beter om lagere waarden te gebruiken. Ik verhoog ze weer na afloop van de taak, mochten er verschillende knooppunten worden gebruikt.
- Venster 'Back-up/Scan': Lange mapdoorlopen wissen de cache. Tijdelijk kan een hoger Waarde (bijv. 180) om tijdens de back-up te voorkomen dat dentries/inodes het RAM-geheugen volmaken – daarna zet ik de waarde weer terug.
- Negatieve Dentries: Ook niet-bestaande bestanden (404) worden in de cache opgeslagen. Webworkloads met veel foutieve toegangsverzoeken presteren aantoonbaar beter als de VFS-cache niet te agressief wordt geleegd.
- Streaming/Sequentiële I/O: Hier speelt de paginacache een dominante rol; te lage waarden leveren weinig op en leggen onnodig beslag op het RAM-geheugen. Ik houd het rond de 100 of iets daarboven.
# Voorbeeld: tijdens een volledige back-up iets agressiever te werk gaan
sudo sysctl -w vm.vfs_cache_pressure=180
# Na de back-up weer terug naar de eerder vastgestelde optimale waarde
sudo sysctl -w vm.vfs_cache_pressure=60
Automatisering en governance
Na succesvolle tests neem ik de instelling op in mijn standaardbuilds. Het is belangrijk dat teams weten dat, waarom er een waarde is gekozen en wanneer dit moet worden gecontroleerd (bijvoorbeeld na een wijziging van de versie of de workload).
- Configuratiebeheer: Ik stel per rol (web, database, bestandsserver) standaardinstellingen in /etc/sysctl.d/ in en verspreid deze centraal.
- Driftcontrole: Er worden regelmatig audits uitgevoerd om te controleren of de live-waarden en de repository met elkaar overeenkomen.
- Hardloopboeken: Ik leg meetstappen, drempelwaarden voor rollback en noodprocedures (bijv. terugzetten naar 100) vast.
#-rol: webserver (voorbeeld)
cat <<'EOF' | sudo tee /etc/sysctl.d/50-web-vfs.conf
vm.vfs_cache_pressure = 60
EOF
sudo sysctl --system
vm.vfs_cache_pressure en andere kernelparameters
Een goed resultaat ontstaat pas in samenspel met vm.swappiness en de drempelwaarden voor dirty pages. Een lagere swappiness (bijv. 10–20) zorgt ervoor dat processen vaker in het RAM blijven en voorkomt onnodige uitwisseling. Met vm.dirty_background_ratio en vm.dirty_ratio regel ik hoe vroeg het systeem gewijzigde pagina’s wegschrijft, zodat schrijfpieken niet alles blokkeren. Ik stel deze waarden zo af dat het opzoeken van metagegevens snel blijft en schrijfbewerkingen volgens plan verlopen. Ik maak hier gebruik van een beknopt overzicht van de interactie tussen bestandscaches: Overzicht van bestandssysteemcaching.
Aanbevelingen voor hostingomgevingen en WordPress
Veel thema’s, plug-ins en media genereren talloze kleine bestanden, en daarom is een krachtige VFS-cache merkbaar helpt. Ik begin met 100, verlaag dit bij voldoende RAM naar 80, later naar 60, en controleer de responstijden, het 95e percentiel van de latenties en CPU-steal. Als er nog voldoende geheugen overblijft, test ik 50 en valideer ik dit opnieuw tijdens de avondpiek of tijdens campagnes. Als de latenties dalen zonder dat swap of de OOM-killer in werking treden, maak ik de instelling permanent. Tegelijkertijd houd ik de paginacache in de gaten, zodat beide caches elkaar op een zinvolle manier aanvullen.
Samenvatting
Met vm.vfs_cache_pressure regel ik de Saldo Ik pas dit heel gericht aan, afhankelijk van snelle metadata-zoekopdrachten en beschikbare RAM. Voor webgerichte workloads verlaag ik de waarde enigszins, voor geheugenintensieve applicaties verhoog ik deze. Elke wijziging onderbouw ik met meetwaarden voor IO-latenties, cache-hits en swap-activiteit. In combinatie met vm.swappiness en de dirty-parameters bereik ik een stabiel geheugenbeheer. Zo maak ik efficiënt gebruik van de Linux-bestandssysteemcache en houd ik de responstijden onder belasting betrouwbaar laag.
