vm.vfs_cache_pressure forklaret – Sådan udnytter du Linux-filsystemets cache optimalt

Jeg viser, hvordan kernelparameteren vm.vfs_cache_pressure hvordan VFS-cachen vægtes i forhold til sidecachen, og hvilke værdier der giver hastighedsgevinster ved et reelt belastningsprofil. Med klare trin justerer jeg denne indstilling, måler effekterne og udnytter dermed Filsystem-cache optimalt.

Centrale punkter

For at komme hurtigt i gang vil jeg sammenfatte de vigtigste aspekter ved tuning af VFS-cacher sammen. På den måde holder jeg øje med indvirkningen på metadata-opslag, IO-belastning og RAM-belastning, når jeg vælger værdien. Disse punkter hjælper mig med at optimere typiske serverroller på en sikker og gentagelig måde.

• Virkningsprincip: Bestemmer, hvor aggressivt kernen frigiver dentries/inodes i forhold til sidecachen.
• Standardindstilling: 100 betyder en afbalanceret justering uden fortrinsbehandling.
• Lave værdier: 50–80 holder metadata længere i RAM og fremskynder filopslag.
• Høje værdier: 120–200 frigiver VFS-cacher hurtigere og skaber plads til processer.
• Øvelse: Ændre, måle og dokumentere trin for trin – først derefter foretage yderligere tilpasninger.

Jeg anvender disse principper konsekvent for at finde den rette balance mellem Cache-hitrate og ledig RAM. Derefter justerer jeg vm.vfs_cache_pressure i små trin, overvåger belastningstoppe og korrigerer om nødvendigt. På den måde opnår jeg stabile responstider uden uventede hukommelsesflaskehalse.

Hvad er vm.vfs_cache_pressure?

Denne parameter styrer, hvor strengt kernelen behandler VFS-cache i modsætning til andre lagringsformer rydder den plads, så snart RAM-pladsen bliver knap. I VFS-cachen havner dentries og inodes, altså mappeindgange og filmetadata, som mærkbart fremskynder filsøgninger. En værdi på 100 behandler VFS-cachen og sidecachen ens, mens lavere værdier foretrækker at holde metadata i RAM. Højere værdier får kernen til at kassere VFS-poster tidligere og frigive hukommelse hurtigere. Jeg bruger denne indstilling målrettet til at holde antallet af metadata-hits højt ved web-, fil- og CMS-arbejdsbelastninger uden at fortrænge processer. På den måde styrer jeg balancen mellem Opslagshastighed og ledig RAM på en meget direkte måde.

Hvordan fungerer VFS-cachen i detaljer?

Det virtuelle filsystem udgør et fælles lag for ext4, XFS, Btrfs og lignende og gemmer Dentries og inoder i RAM, så mappe-scanninger og gentagne adgangsforespørgsler forbliver hurtige. Page-cachen indeholder derimod de egentlige filblokke; de to cacher supplerer hinanden, men konkurrerer om hukommelse, når presset stiger. Jo flere små filer og hyppige gentagne adgangshandlinger der er, desto større fordel har applikationen af en høj metadata-hitrate. Det er netop her, vm.vfs_cache_pressure kommer ind i billedet: Jeg bestemmer, om Linux skal beholde disse metadata eller hurtigt fortrænge dem. For mere dybdegående aspekter af sidecachen anvender jeg supplerende den kompakte Page-Cache Performance Booster som baggrundsviden, så jeg kan vurdere VFS og sidecache i den rette sammenhæng.

Standardværdi og typiske værdiintervaller

På de fleste systemer er værdien indstillet til 100 og danner dermed et afbalanceret grundlag for de første tests. Hvis jeg sænker værdien, prioriterer jeg metadata og sikrer hurtige opslag, hvilket især er en fordel ved mange små filer. Hvis jeg hæver værdien, afvikler Linux VFS-poster hurtigere og skaber mere bufferplads til applikationer eller sidebufferen. Ekstreme værdier som 0 eller værdier over 500 håndterer jeg kun med stor forsigtighed, da de kan udløse voldsom adfærd og fremkalde bivirkninger. I dagligdagen starter jeg ved 100, bevæger mig fremad i trin på 20–40 point og måler effekten på IO-latens og svartider.

Værdi	Betydning	Hvornår skal man bruge	Risiko/Bemærkning
< 100 (f.eks. 50–80)	VFS-cachen forbliver længere i RAM’en	Mange små filer, hyppige opslag	Mere RAM-allokering til Metadata
100	Afbalanceret justering	Et solidt udgangspunkt for målinger	God Baseline-værdi
> 100 (f.eks. 120–200)	VFS-cachen frigives mere aggressivt	Mangel på RAM, databaser med egen cache	Mulig opslagslatens
Ekstrem (0, > 500)	Markante forskydninger	Særlige tilfælde – kort test	Trussel mod stabiliteten og Ydelse

Med denne skabelon kan jeg hurtigt se, hvilken retning der passer, uden at gå for langt. Jeg undgår store spring og dokumenterer hver ændring detaljeret. På den måde forbliver den tilbagelagte vej altid overskuelig, og jeg sikrer en præcis sammenligning med tidligere målepunkter.

Rolle i oprydningen af lageret

Under pres er kernen nødt til at frigive RAM, og det er netop her, at vm.vfs_cache_pressure fastlægger fordelingen mellem VFS-cache, sidecache og proceshukommelse. Lave værdier holder mappe- og inode-poster længere i hukommelsen, hvilket sikrer hurtig behandling af mappeadgang og gentagne filåbninger. Høje værdier frigiver hukommelsen tidligere og giver mere plads til processer eller sidecachen, hvilket kan være nyttigt, når RAM-hukommelsen er knap. Jeg holder her især øje med IO-latenser, da en for tom metadatacache bremser filsøgningen. I samspil med strategier for frigørelse af sidecache giver denne indsigt mig Fjernelse fra sidecachen værdifulde praktiske indsigter, så jeg kan træffe beslutninger på baggrund af fakta.

Målemetode: Gøre VFS-cachen gennemsigtig

Inden jeg ændrer noget, gør jeg det synligt, hvor hukommelsen ligger i og hvad bliver fortrængt. På den måde kan jeg se, om metadata virkelig er flaskehalsen – eller om det er sidecachen, processerne eller de »dirty pages«, der dominerer.

• /proc/meminfo: Jeg undersøger InodeCache, Cached, Buffers, SReclaimable og SUnreclaim for at vurdere andelen og muligheden for genvinding.
• Slabtop: Live-visning af slabs, især dentry, inode_cache, ext4_inode_cache og xfs_inode. Så kan jeg se, om dentries/inodes vokser eller krymper.
• IO-sti: Med vmstat/iostat overvåger jeg læselatenser og ser, om antallet af diskadgange stiger ved opslag.

# Hurtigt overblik
grep -E 'InodeCache|SReclaimable|SUnreclaim|Cached|Buffers' /proc/meminfo

# Slab-fordeling (sorteret efter størrelse)
sudo slabtop -s c

# Filtrer kun dentry-/inode-lignende slabs fra
grep -Ei 'dentry|inode' /proc/slabinfo | sort -k3 -nr | head

# IO- og hukommelsestendenser pr. sekund
vmstat 1
iostat -x 1

Jeg mener, at fortolkningen er klar: Hvis SReclaimable vokser sammen med dentry/inode-slabs, og IO-latenser samtidig stiger ikke, bekræfter dette, at metadatacachen fungerer effektivt. Hvis disse værdier ofte falder til nul og stiger hurtigt ved adgang til mapper, er vm.vfs_cache_pressure sandsynligvis indstillet for aggressivt.

Praksis: Aflæse og ændre den aktuelle værdi

Kontrollen kan udføres fra kommandolinjen på få sekunder og uden Genstart. Jeg læser den aktuelle værdi ud og skriver først testværdier midlertidigt, så jeg straks kan gennemføre tilbagespring i testvinduet. Til produktive justeringer opretter jeg indtastninger i /etc/sysctl.conf eller en fil i /etc/sysctl.d/, genindlæser dem og noterer ændringen i min dokumentation. Jeg tester hvert trin under realistisk belastning, ikke kun i tomgang, så effekterne bliver synlige. På den måde sikrer jeg præcise før-efter-sammenligninger og vurderer ændringen ud fra målbare nøgletal.

# Kontroller den aktuelle værdi
cat /proc/sys/vm/vfs_cache_pressure
# eller
sysctl vm.vfs_cache_pressure

# Test midlertidigt (indtil genstart)
sudo sysctl -w vm.vfs_cache_pressure=60
# Alternativt
echo 60 | sudo tee /proc/sys/vm/vfs_cache_pressure

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

Linux-cacheoptimering: relevante scenarier

På hostingplatforme med mange statiske ressourcer, filarkiver eller applikationer med egen buffer er det en god idé at foretage en målrettet vægtning i VFS-cachen. Webservere med mange små filer har stor fordel af lavere værdier, da opslag sjældnere rammer SSD/HDD. Filservere med blandede filstørrelser kan bruge moderat lavere værdier, hvis der er tilstrækkelig RAM til rådighed. Databaseservere med højt RAM-forbrug og stor DB-cache foretrækker højere værdier, så processerne får plads. Jeg vurderer disse mønstre i hvert enkelt tilfælde ud fra overvågningsdata, så indstillingerne passer til den faktiske adgangssammensætning.

Webserver med mange statiske filer

Hvad angår CSS, JS og billeder, foretrækker jeg at opbevare metadataene lidt længere i Cache. Værdier mellem 50 og 80 har ofte vist sig at fungere godt, fordi genåbning af filer foregår hurtigere. Jeg undersøger nøje IO-spidsbelastninger under trafikspidser og sammenligner responstider før og efter ændringen. Hvis latenstiderne forbliver stabile, og omkostningerne ved 404-opslag falder, er vi på rette spor. Jeg holder øje med RAM-udnyttelsen, så processerne har tilstrækkelig plads trods en større metadatacache.

Filservere eller NAS-systemer

Mange brugerbesøg og skift af mappe drager fordel af lavere indtil der opnås afbalancerede værdier. Hvis der er tilstrækkelig RAM, sætter jeg værdien nærmere 50–80; hvis der er knap med hukommelse, holder jeg mig tættere på 100. Jeg tjekker, om mappeoversigter fortsat vises flydende, og om snapshots/backups ikke fortrænger cachen for meget. Hvis IO-latensen stiger ved spidsbelastninger, justerer jeg forsigtigt værdien opad. På den måde opretholder jeg balancen mellem brugervenlighed og ledig arbejdshukommelse.

Databaseservere og systemer med begrænset lagerplads

Databaser har deres egen buffer-cache, derfor giver jeg den Proceshukommelse har som regel forrang. Værdier mellem 120 og 200 signalerer, at VFS-cacherne hellere skal tømmes for at frigøre RAM. Her holder jeg øje med applikationens forespørgselsforsinkelser og page-fault-mønstre. Hvis databasen bremses, fordi systemet begynder at swappe, hæver jeg værdien en smule og reducerer samtidig vm.swappiness. Denne tilgang forhindrer, at metadata unødigt optager plads, som databasen bedre kan udnytte.

Eksempler på arbejdsbyrde og vejledende tal

Jeg starter med 100 og reducerer i trin på 20 for web-relaterede Arbejdsbyrder og øger i trin på 20 for processer, der kræver meget hukommelse. Jeg tester hvert trin i mindst én spidsbelastningsfase, så jeg kan se, hvordan det påvirker latenstider, cache-hits og swap-aktivitet. Hvis man vil dykke dybere ned i emnet, kan man finde en kortfattet beskrivelse i Page-Cache Performance Booster Yderligere baggrundsoplysninger om filcache-strategier, som jeg tager i betragtning sideløbende. Når måleværdierne stemmer overens med målsætningen, fastfryser jeg konfigurationen og dokumenterer nøgletallene. På den måde forbliver optimeringen reproducerbar, og jeg kan hurtigt foretage justeringer senere.

Risici og faldgruber

Hvis jeg sætter værdien for lavt, kan kernen næsten ikke frigøre VFS-poster, hvilket ved spidsbelastninger kan føre til OOM‑risici. Hvis jeg hæver den for meget, stiger ventetiden ved filopslag og skift mellem mapper, fordi metadataene skal indlæses på ny. Uden test under reel belastning er der risiko for, at man drager forkerte konklusioner ud fra perioder med lav aktivitet. Pludselige udsving gør vurderingen vanskelig, derfor går jeg trinvis frem. Jeg noterer hver ændring med tidspunkt, belastningsprofil og måleværdier, så årsagerne forbliver klare.

Overvågning og nøgletal

Om det kan betale sig at foretage en tilpasning, viser konkrete tal Metrikker. Jeg overvåger RAM-forbruget, fordelingen mellem cacher og processer, IO-forsinkelser og swap-aktivitet. Derudover analyserer jeg cache-hit-procenter og page-fault-tendenser for hurtigt at opdage bivirkninger. Især med mange små filer bemærkes forbedringer i »time-to-first-byte«. Hvis IO-latensen forbliver lav, og swappingen mindskes, bekræfter det, at vi er på rette kurs.

Tuning-Playbook: Fra hypotese til pålidelig indstilling

En struktur forhindrer, at man arbejder i blinde. Jeg følger en fast fremgangsmåde, så resultaterne bliver pålidelige, og mine kolleger kan følge med i de enkelte trin.

1. Registrer udgangsværdien: vm.vfs_cache_pressure=100, 24–72 timers realistisk belastning. Sikkerhedskopier nøgletal (latenser: median/95./99., IO-ventetid, CPU-steal, swap-aktivitet, inode/dentry-størrelse).
2. Formulere en hypotese: „Mange små filer, opslag er ressourcekrævende – lavere værdier gør det hurtigere“ eller „Mangel på RAM – højere værdier holder processerne fri“.
3. Ændre trin for trin: ±20 til ±40 point. Der skal måles mindst én spidsfase pr. trin.
4. Sammenlign: Jeg undersøger, om SLO’erne (f.eks. 95.-percentilen) bliver pålideligt bedre, uden flere swap- eller OOM-hændelser.
5. Rollback-kriterium: Hvis 95./99.-latenserne stiger, IO-ventetiderne øges eller cache-misserne bliver hyppigere, tager jeg et skridt tilbage.
6. Freeze & dokumentation: Noter den endelige værdi, datoen, belastningsvinduet og nøgletallene.

# Hurtig test for kontrollerede målevinduer (kun vedligeholdelse!)
# Før: Tag et øjebliksbillede af nøgletallene
date; free -h; grep -E 'InodeCache|Cached' /proc/meminfo; vmstat 1 5

sudo sysctl -w vm.vfs_cache_pressure=80
# Afvent belastningstest/spidsbelastning, registrer derefter nøgletallene igen og sammenlign

Filsystemer og monteringsindstillinger: Konteksten er afgørende

Effekten af vm.vfs_cache_pressure afhænger også af filsystemet og monteringsindstillingerne. Jeg vurderer disse faktorer ud fra:

• relatime/noatime: Forhindrer hyppige atime-skrivninger. noatime mindsker IO-belastningen ved mange læsninger, hvilket gør fordelene ved metadata mere tydelige.
• dovenskab: Forsinker opdateringer af metadata i RAM; dette udjævner spidser, men påvirker tidspunktet for tømning.
• ext4 vs. XFS vs. Btrfs: Forskellige inode-strukturer og Shrinker-adfærd. Jeg måler altid på mål-FS’en, i stedet for at overføre antagelser.
• NFS/Net-FS: Caching og ugyldiggørelse af attributter kan begrænse fordelene ved VFS. Aggressiv frigivelse (høje værdier) medfører i så fald en stigning i antallet af fjernopslag.
• OverlayFS/FUSE: Mange små metadataprocesser drager stor fordel af VFS-cachen; jeg holder værdierne på et ret moderat til lavt niveau, så længe der er RAM til rådighed.

Aspekter vedrørende containere og cgroups

I container-miljøer husker jeg altid, at vm.vfs_cache_pressure er en på tværs af værter Knapper. Ændringerne vedrører alle Pods/containere på noden. Derfor vælger jeg en forsigtig tilgang og koordinerer optimeringen på node-niveau.

• Lagringsgrænser: Memory-Cgroups begrænser proces- og sidecache; slab-hukommelse kan medregnes proportionalt. Jeg observerer Pod-OOM’er og Node-Pressure-hændelser i denne sammenhæng.
• Arbejdsbyrdens sammensætning: Knudepunkter, der kører både DB-pods og web-frontends, får ingen ekstreme værdier. Hvis det er nødvendigt, fordeler jeg rollerne på forskellige knudepunkter.
• Udrulning: Først Canaries (en node), derefter gradvis udrulning. Jeg dokumenterer ændringerne i node-baseline (sysctl.d) og noterer de berørte deployments.

Særlige tilfælde fra praksis

Nogle mønstre kan man målrettet tackle, hvis jeg kender årsagerne:

• CI/Build-opgaver: Mange korte filadgange og katalogscanninger drager fordel af lavere værdier. Jeg hæver dem igen, når jobbet er afsluttet, hvis der anvendes blandede noder.
• Vinduet »Backup/Scan«: Lange kataloggennemløb overskriver cachen. Midlertidigt kan en højere Værdien (f.eks. 180) forhindrer under sikkerhedskopieringen, at dentries/inodes fylder RAM’en – bagefter nulstiller jeg den.
• Negative indtastninger: Ikke-eksisterende filer (404) gemmes også i cachen. Web-workloads med hyppige fejladgang forsyninger opnår målbare forbedringer, hvis VFS-cachen ikke tømmes for aggressivt.
• Streaming/sekventiel I/O: Her er det sidecachen, der dominerer; for lave værdier giver ikke meget og optager unødigt RAM. Jeg holder mig tæt på 100 eller lidt derover.

# Eksempel: Vær lidt mere aggressiv under en fuld sikkerhedskopiering
sudo sysctl -w vm.vfs_cache_pressure=180
# Efter sikkerhedskopieringen skal den tidligere fastlagte optimale værdi genindstilles
sudo sysctl -w vm.vfs_cache_pressure=60

Automatisering og styring

Efter vellykkede test integrerer jeg indstillingen i mine standard-builds. Det er vigtigt, at teams ved, hvorfor der er valgt en værdi, og når der skal kontrolleres (f.eks. efter ændringer af version eller arbejdsbelastning).

• Konfigurationsstyring: Jeg definerer standardindstillinger for hver rolle (web, database, filserver) i /etc/sysctl.d/ og distribuerer dem centralt.
• Driftkontrol: Der foretages regelmæssige revisioner for at kontrollere, om live-værdierne og repositoryet stemmer overens.
• Løbebøger: Jeg dokumenterer måleprocedurer, grænseværdier for rollback og nødprocedurer (f.eks. nulstilling til 100).

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

vm.vfs_cache_pressure og andre kerneparametre

Et godt resultat opnås først i samspil med vm.swappiness og tærskelværdierne for »dirty pages«. En lavere »swappiness« (f.eks. 10–20) holder processerne i RAM’en i højere grad og undgår unødvendig udlagring. Med vm.dirty_background_ratio og vm.dirty_ratio regulerer jeg, hvor tidligt systemet skriver ændrede sider væk, så skrivespidsbelastninger ikke blokerer det hele. Jeg tilpasser disse værdier, så metadata-opslag forbliver hurtige, og skriveoperationer forløber planlagt. Her bruger jeg en overskuelig oversigt over samspillet mellem filcacher: Oversigt over filsystem-caching.

Anbefalinger til hostingmiljøer og WordPress

Mange temaer, plugins og mediefiler genererer utallige små filer, hvorfor en kraftig VFS-cache hjælper mærkbart. Jeg starter med 100, sænker til 80, hvis der er tilstrækkelig RAM, senere til 60, og tjekker responstider, 95. percentil for latenstider og CPU-steal. Hvis hukommelsen stadig er tilstrækkelig, tester jeg 50 og validerer igen i aftenens spidsbelastning eller under kampagner. Hvis latenstiderne falder, uden at swap eller OOM-killer træder i kraft, fastlægger jeg indstillingen permanent. Parallelt holder jeg øje med sidecachen, så de to cacher supplerer hinanden på en fornuftig måde.

Sammenfatning

Med vm.vfs_cache_pressure styrer jeg Balance mellem hurtige metadatasøgninger og ledig RAM på en meget målrettet måde. Til webrelaterede arbejdsbelastninger sænker jeg værdien moderat, mens jeg hæver den for applikationer, der kræver meget hukommelse. Hver ændring underbygger jeg med måleværdier for IO-latenser, cache-hits og swap-aktivitet. I kombination med vm.swappiness og dirty-parametrene opnår jeg en stabil hukommelsesstyring. På den måde udnytter jeg Linux-filsystemcachen effektivt og holder responstiderne pålideligt lave under belastning.