{"id":20874,"date":"2026-08-21T18:22:37","date_gmt":"2026-08-21T16:22:37","guid":{"rendered":"https:\/\/webhosting.de\/vm-vfs-cache-pressure-linux-filesystem-cache-tuning-optimierung\/"},"modified":"2026-08-21T18:22:37","modified_gmt":"2026-08-21T16:22:37","slug":"vm-vfs-cache-belastning-linux-filsystem-cache-justering-optimering","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/vm-vfs-cache-pressure-linux-filesystem-cache-tuning-optimierung\/","title":{"rendered":"vm.vfs_cache_pressure forklaret \u2013 S\u00e5dan udnytter du Linux-filsystemets cache optimalt"},"content":{"rendered":"<p>Jeg viser, hvordan kernelparameteren <strong>vm.vfs_cache_pressure<\/strong> hvordan VFS-cachen v\u00e6gtes i forhold til sidecachen, og hvilke v\u00e6rdier der giver hastighedsgevinster ved et reelt belastningsprofil. Med klare trin justerer jeg denne indstilling, m\u00e5ler effekterne og udnytter dermed <strong>Filsystem-cache<\/strong> optimalt.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<p>For at komme hurtigt i gang vil jeg sammenfatte de vigtigste aspekter ved tuning af <strong>VFS-cacher<\/strong> sammen. P\u00e5 den m\u00e5de holder jeg \u00f8je med indvirkningen p\u00e5 metadata-opslag, IO-belastning og RAM-belastning, n\u00e5r jeg v\u00e6lger v\u00e6rdien. Disse punkter hj\u00e6lper mig med at optimere typiske serverroller p\u00e5 en sikker og gentagelig m\u00e5de.<\/p>\n\n<ul>\n  <li><strong>Virkningsprincip<\/strong>: Bestemmer, hvor aggressivt kernen frigiver dentries\/inodes i forhold til sidecachen.<\/li>\n  <li><strong>Standardindstilling<\/strong>: 100 betyder en afbalanceret justering uden fortrinsbehandling.<\/li>\n  <li><strong>Lave v\u00e6rdier<\/strong>: 50\u201380 holder metadata l\u00e6ngere i RAM og fremskynder filopslag.<\/li>\n  <li><strong>H\u00f8je v\u00e6rdier<\/strong>: 120\u2013200 frigiver VFS-cacher hurtigere og skaber plads til processer.<\/li>\n  <li><strong>\u00d8velse<\/strong>: \u00c6ndre, m\u00e5le og dokumentere trin for trin \u2013 f\u00f8rst derefter foretage yderligere tilpasninger.<\/li>\n<\/ul>\n\n<p>Jeg anvender disse principper konsekvent for at finde den rette balance mellem <strong>Cache-hitrate<\/strong> og ledig RAM. Derefter justerer jeg vm.vfs_cache_pressure i sm\u00e5 trin, overv\u00e5ger belastningstoppe og korrigerer om n\u00f8dvendigt. P\u00e5 den m\u00e5de opn\u00e5r jeg stabile responstider uden uventede hukommelsesflaskehalse.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-cache-optimierung-4756.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvad er vm.vfs_cache_pressure?<\/h2>\n\n<p>Denne parameter styrer, hvor strengt kernelen behandler <strong>VFS-cache<\/strong> i mods\u00e6tning til andre lagringsformer rydder den plads, s\u00e5 snart RAM-pladsen bliver knap. I VFS-cachen havner dentries og inodes, alts\u00e5 mappeindgange og filmetadata, som m\u00e6rkbart fremskynder fils\u00f8gninger. En v\u00e6rdi p\u00e5 100 behandler VFS-cachen og sidecachen ens, mens lavere v\u00e6rdier foretr\u00e6kker at holde metadata i RAM. H\u00f8jere v\u00e6rdier f\u00e5r kernen til at kassere VFS-poster tidligere og frigive hukommelse hurtigere. Jeg bruger denne indstilling m\u00e5lrettet til at holde antallet af metadata-hits h\u00f8jt ved web-, fil- og CMS-arbejdsbelastninger uden at fortr\u00e6nge processer. P\u00e5 den m\u00e5de styrer jeg balancen mellem <strong>Opslagshastighed<\/strong> og ledig RAM p\u00e5 en meget direkte m\u00e5de.<\/p>\n\n<h2>Hvordan fungerer VFS-cachen i detaljer?<\/h2>\n\n<p>Det virtuelle filsystem udg\u00f8r et f\u00e6lles lag for ext4, XFS, Btrfs og lignende og gemmer <strong>Dentries<\/strong> og inoder i RAM, s\u00e5 mappe-scanninger og gentagne adgangsforesp\u00f8rgsler forbliver hurtige. Page-cachen indeholder derimod de egentlige filblokke; de to cacher supplerer hinanden, men konkurrerer om hukommelse, n\u00e5r presset stiger. Jo flere sm\u00e5 filer og hyppige gentagne adgangshandlinger der er, desto st\u00f8rre fordel har applikationen af en h\u00f8j 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\u00e6nge dem. For mere dybdeg\u00e5ende aspekter af sidecachen anvender jeg supplerende den kompakte <a href=\"https:\/\/webhosting.de\/da\/ydelsesforbedring-af-linux-sidecachen\/\">Page-Cache Performance Booster<\/a> som baggrundsviden, s\u00e5 jeg kan vurdere VFS og sidecache i den rette sammenh\u00e6ng.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linuxcachemeeting1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Standardv\u00e6rdi og typiske v\u00e6rdiintervaller<\/h2>\n\n<p>P\u00e5 de fleste systemer er v\u00e6rdien indstillet til <strong>100<\/strong> og danner dermed et afbalanceret grundlag for de f\u00f8rste tests. Hvis jeg s\u00e6nker v\u00e6rdien, prioriterer jeg metadata og sikrer hurtige opslag, hvilket is\u00e6r er en fordel ved mange sm\u00e5 filer. Hvis jeg h\u00e6ver v\u00e6rdien, afvikler Linux VFS-poster hurtigere og skaber mere bufferplads til applikationer eller sidebufferen. Ekstreme v\u00e6rdier som 0 eller v\u00e6rdier over 500 h\u00e5ndterer jeg kun med stor forsigtighed, da de kan udl\u00f8se voldsom adf\u00e6rd og fremkalde bivirkninger. I dagligdagen starter jeg ved 100, bev\u00e6ger mig fremad i trin p\u00e5 20\u201340 point og m\u00e5ler effekten p\u00e5 <strong>IO-latens<\/strong> og svartider.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>V\u00e6rdi<\/th>\n      <th>Betydning<\/th>\n      <th>Hvorn\u00e5r skal man bruge<\/th>\n      <th>Risiko\/Bem\u00e6rkning<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>&lt; 100 (f.eks. 50\u201380)<\/td>\n      <td>VFS-cachen forbliver l\u00e6ngere i RAM\u2019en<\/td>\n      <td>Mange sm\u00e5 filer, hyppige opslag<\/td>\n      <td>Mere RAM-allokering til <strong>Metadata<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>100<\/td>\n      <td>Afbalanceret justering<\/td>\n      <td>Et solidt udgangspunkt for m\u00e5linger<\/td>\n      <td>God <strong>Baseline<\/strong>-v\u00e6rdi<\/td>\n    <\/tr>\n    <tr>\n      <td>&gt; 100 (f.eks. 120\u2013200)<\/td>\n      <td>VFS-cachen frigives mere aggressivt<\/td>\n      <td>Mangel p\u00e5 RAM, databaser med egen cache<\/td>\n      <td>Mulig opslagslatens<\/td>\n    <\/tr>\n    <tr>\n      <td>Ekstrem (0, &gt; 500)<\/td>\n      <td>Markante forskydninger<\/td>\n      <td>S\u00e6rlige tilf\u00e6lde \u2013 kort test<\/td>\n      <td>Trussel mod stabiliteten og <strong>Ydelse<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Med denne skabelon kan jeg hurtigt se, hvilken retning der passer, uden at g\u00e5 for langt. Jeg undg\u00e5r store spring og dokumenterer hver \u00e6ndring detaljeret. P\u00e5 den m\u00e5de forbliver den tilbagelagte vej altid overskuelig, og jeg sikrer en pr\u00e6cis sammenligning med tidligere m\u00e5lepunkter.<\/p>\n\n<h2>Rolle i oprydningen af lageret<\/h2>\n\n<p>Under pres er kernen n\u00f8dt til at frigive RAM, og det er netop her, at vm.vfs_cache_pressure fastl\u00e6gger fordelingen mellem <strong>VFS-cache<\/strong>, sidecache og proceshukommelse. Lave v\u00e6rdier holder mappe- og inode-poster l\u00e6ngere i hukommelsen, hvilket sikrer hurtig behandling af mappeadgang og gentagne fil\u00e5bninger. H\u00f8je v\u00e6rdier frigiver hukommelsen tidligere og giver mere plads til processer eller sidecachen, hvilket kan v\u00e6re nyttigt, n\u00e5r RAM-hukommelsen er knap. Jeg holder her is\u00e6r \u00f8je med IO-latenser, da en for tom metadatacache bremser fils\u00f8gningen. I samspil med strategier for frig\u00f8relse af sidecache giver denne indsigt mig <a href=\"https:\/\/webhosting.de\/da\/server-page-cache-eviction-linux-memory-print-optimisation-insight\/\">Fjernelse fra sidecachen<\/a> v\u00e6rdifulde praktiske indsigter, s\u00e5 jeg kan tr\u00e6ffe beslutninger p\u00e5 baggrund af fakta.<\/p>\n\n<h2>M\u00e5lemetode: G\u00f8re VFS-cachen gennemsigtig<\/h2>\n\n<p>Inden jeg \u00e6ndrer noget, g\u00f8r jeg det synligt, <strong>hvor<\/strong> hukommelsen ligger i og <strong>hvad<\/strong> bliver fortr\u00e6ngt. P\u00e5 den m\u00e5de kan jeg se, om metadata virkelig er flaskehalsen \u2013 eller om det er sidecachen, processerne eller de \u00bbdirty pages\u00ab, der dominerer.<\/p>\n\n<ul>\n  <li><strong>\/proc\/meminfo<\/strong>: Jeg unders\u00f8ger InodeCache, Cached, Buffers, SReclaimable og SUnreclaim for at vurdere andelen og muligheden for genvinding.<\/li>\n  <li><strong>Slabtop<\/strong>: Live-visning af slabs, is\u00e6r dentry, inode_cache, ext4_inode_cache og xfs_inode. S\u00e5 kan jeg se, om dentries\/inodes vokser eller krymper.<\/li>\n  <li><strong>IO-sti<\/strong>: Med vmstat\/iostat overv\u00e5ger jeg l\u00e6selatenser og ser, om antallet af diskadgange stiger ved opslag.<\/li>\n<\/ul>\n\n<pre><code># Hurtigt overblik\ngrep -E 'InodeCache|SReclaimable|SUnreclaim|Cached|Buffers' \/proc\/meminfo\n\n# Slab-fordeling (sorteret efter st\u00f8rrelse)\nsudo slabtop -s c\n\n# Filtrer kun dentry-\/inode-lignende slabs fra\ngrep -Ei 'dentry|inode' \/proc\/slabinfo | sort -k3 -nr | head\n\n# IO- og hukommelsestendenser pr. sekund\nvmstat 1\niostat -x 1\n<\/code><\/pre>\n\n<p>Jeg mener, at fortolkningen er klar: Hvis SReclaimable vokser sammen med dentry\/inode-slabs, og IO-latenser samtidig stiger <em>ikke<\/em>, bekr\u00e6fter dette, at metadatacachen fungerer effektivt. Hvis disse v\u00e6rdier ofte falder til nul og stiger hurtigt ved adgang til mapper, er vm.vfs_cache_pressure sandsynligvis indstillet for aggressivt.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-cache-optimization-tips-5467.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praksis: Afl\u00e6se og \u00e6ndre den aktuelle v\u00e6rdi<\/h2>\n\n<p>Kontrollen kan udf\u00f8res fra kommandolinjen p\u00e5 f\u00e5 sekunder og uden <strong>Genstart<\/strong>. Jeg l\u00e6ser den aktuelle v\u00e6rdi ud og skriver f\u00f8rst testv\u00e6rdier midlertidigt, s\u00e5 jeg straks kan gennemf\u00f8re tilbagespring i testvinduet. Til produktive justeringer opretter jeg indtastninger i \/etc\/sysctl.conf eller en fil i \/etc\/sysctl.d\/, genindl\u00e6ser dem og noterer \u00e6ndringen i min dokumentation. Jeg tester hvert trin under realistisk belastning, ikke kun i tomgang, s\u00e5 effekterne bliver synlige. P\u00e5 den m\u00e5de sikrer jeg pr\u00e6cise f\u00f8r-efter-sammenligninger og vurderer \u00e6ndringen ud fra m\u00e5lbare n\u00f8gletal.<\/p>\n\n<pre><code># Kontroller den aktuelle v\u00e6rdi\ncat \/proc\/sys\/vm\/vfs_cache_pressure\n# eller\nsysctl vm.vfs_cache_pressure\n\n# Test midlertidigt (indtil genstart)\nsudo sysctl -w vm.vfs_cache_pressure=60\n# Alternativt\necho 60 | sudo tee \/proc\/sys\/vm\/vfs_cache_pressure\n\n# Indstil permanent\necho \"vm.vfs_cache_pressure = 60\" | sudo tee -a \/etc\/sysctl.conf\nsudo sysctl -p\n<\/code><\/pre>\n\n<h2>Linux-cacheoptimering: relevante scenarier<\/h2>\n\n<p>P\u00e5 hostingplatforme med mange statiske ressourcer, filarkiver eller applikationer med egen buffer er det en god id\u00e9 at foretage en m\u00e5lrettet <strong>v\u00e6gtning<\/strong> i VFS-cachen. Webservere med mange sm\u00e5 filer har stor fordel af lavere v\u00e6rdier, da opslag sj\u00e6ldnere rammer SSD\/HDD. Filservere med blandede filst\u00f8rrelser kan bruge moderat lavere v\u00e6rdier, hvis der er tilstr\u00e6kkelig RAM til r\u00e5dighed. Databaseservere med h\u00f8jt RAM-forbrug og stor DB-cache foretr\u00e6kker h\u00f8jere v\u00e6rdier, s\u00e5 processerne f\u00e5r plads. Jeg vurderer disse m\u00f8nstre i hvert enkelt tilf\u00e6lde ud fra overv\u00e5gningsdata, s\u00e5 indstillingerne passer til den faktiske adgangssammens\u00e6tning.<\/p>\n\n<h3>Webserver med mange statiske filer<\/h3>\n<p>Hvad ang\u00e5r CSS, JS og billeder, foretr\u00e6kker jeg at opbevare metadataene lidt l\u00e6ngere i <strong>Cache<\/strong>. V\u00e6rdier mellem 50 og 80 har ofte vist sig at fungere godt, fordi gen\u00e5bning af filer foreg\u00e5r hurtigere. Jeg unders\u00f8ger n\u00f8je IO-spidsbelastninger under trafikspidser og sammenligner responstider f\u00f8r og efter \u00e6ndringen. Hvis latenstiderne forbliver stabile, og omkostningerne ved 404-opslag falder, er vi p\u00e5 rette spor. Jeg holder \u00f8je med RAM-udnyttelsen, s\u00e5 processerne har tilstr\u00e6kkelig plads trods en st\u00f8rre metadatacache.<\/p>\n\n<h3>Filservere eller NAS-systemer<\/h3>\n<p>Mange brugerbes\u00f8g og skift af mappe drager fordel af <strong>lavere<\/strong> indtil der opn\u00e5s afbalancerede v\u00e6rdier. Hvis der er tilstr\u00e6kkelig RAM, s\u00e6tter jeg v\u00e6rdien n\u00e6rmere 50\u201380; hvis der er knap med hukommelse, holder jeg mig t\u00e6ttere p\u00e5 100. Jeg tjekker, om mappeoversigter fortsat vises flydende, og om snapshots\/backups ikke fortr\u00e6nger cachen for meget. Hvis IO-latensen stiger ved spidsbelastninger, justerer jeg forsigtigt v\u00e6rdien opad. P\u00e5 den m\u00e5de opretholder jeg balancen mellem brugervenlighed og ledig arbejdshukommelse.<\/p>\n\n<h3>Databaseservere og systemer med begr\u00e6nset lagerplads<\/h3>\n<p>Databaser har deres egen buffer-cache, derfor giver jeg den <strong>Proceshukommelse<\/strong> har som regel forrang. V\u00e6rdier mellem 120 og 200 signalerer, at VFS-cacherne hellere skal t\u00f8mmes for at frig\u00f8re RAM. Her holder jeg \u00f8je med applikationens foresp\u00f8rgselsforsinkelser og page-fault-m\u00f8nstre. Hvis databasen bremses, fordi systemet begynder at swappe, h\u00e6ver jeg v\u00e6rdien en smule og reducerer samtidig vm.swappiness. Denne tilgang forhindrer, at metadata un\u00f8digt optager plads, som databasen bedre kan udnytte.<\/p>\n\n<h2>Eksempler p\u00e5 arbejdsbyrde og vejledende tal<\/h2>\n\n<p>Jeg starter med 100 og reducerer i trin p\u00e5 20 for web-relaterede <strong>Arbejdsbyrder<\/strong> og \u00f8ger i trin p\u00e5 20 for processer, der kr\u00e6ver meget hukommelse. Jeg tester hvert trin i mindst \u00e9n spidsbelastningsfase, s\u00e5 jeg kan se, hvordan det p\u00e5virker latenstider, cache-hits og swap-aktivitet. Hvis man vil dykke dybere ned i emnet, kan man finde en kortfattet beskrivelse i <a href=\"https:\/\/webhosting.de\/da\/ydelsesforbedring-af-linux-sidecachen\/\">Page-Cache Performance Booster<\/a> Yderligere baggrundsoplysninger om filcache-strategier, som jeg tager i betragtning sidel\u00f8bende. N\u00e5r m\u00e5lev\u00e6rdierne stemmer overens med m\u00e5ls\u00e6tningen, fastfryser jeg konfigurationen og dokumenterer n\u00f8gletallene. P\u00e5 den m\u00e5de forbliver optimeringen reproducerbar, og jeg kan hurtigt foretage justeringer senere.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux_cache_nutzung_4387.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Risici og faldgruber<\/h2>\n\n<p>Hvis jeg s\u00e6tter v\u00e6rdien for lavt, kan kernen n\u00e6sten ikke frig\u00f8re VFS-poster, hvilket ved spidsbelastninger kan f\u00f8re til <strong>OOM<\/strong>\u2011risici. Hvis jeg h\u00e6ver den for meget, stiger ventetiden ved filopslag og skift mellem mapper, fordi metadataene skal indl\u00e6ses p\u00e5 ny. Uden test under reel belastning er der risiko for, at man drager forkerte konklusioner ud fra perioder med lav aktivitet. Pludselige udsving g\u00f8r vurderingen vanskelig, derfor g\u00e5r jeg trinvis frem. Jeg noterer hver \u00e6ndring med tidspunkt, belastningsprofil og m\u00e5lev\u00e6rdier, s\u00e5 \u00e5rsagerne forbliver klare.<\/p>\n\n<h2>Overv\u00e5gning og n\u00f8gletal<\/h2>\n\n<p>Om det kan betale sig at foretage en tilpasning, viser konkrete tal <strong>Metrikker<\/strong>. Jeg overv\u00e5ger 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\u00e6r med mange sm\u00e5 filer bem\u00e6rkes forbedringer i \u00bbtime-to-first-byte\u00ab. Hvis IO-latensen forbliver lav, og swappingen mindskes, bekr\u00e6fter det, at vi er p\u00e5 rette kurs.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linuxcache_4242.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Tuning-Playbook: Fra hypotese til p\u00e5lidelig indstilling<\/h2>\n\n<p>En struktur forhindrer, at man arbejder i blinde. Jeg f\u00f8lger en fast fremgangsm\u00e5de, s\u00e5 resultaterne bliver p\u00e5lidelige, og mine kolleger kan f\u00f8lge med i de enkelte trin.<\/p>\n\n<ol>\n  <li><strong>Registrer udgangsv\u00e6rdien<\/strong>: vm.vfs_cache_pressure=100, 24\u201372 timers realistisk belastning. Sikkerhedskopier n\u00f8gletal (latenser: median\/95.\/99., IO-ventetid, CPU-steal, swap-aktivitet, inode\/dentry-st\u00f8rrelse).<\/li>\n  <li><strong>Formulere en hypotese<\/strong>: \u201eMange sm\u00e5 filer, opslag er ressourcekr\u00e6vende \u2013 lavere v\u00e6rdier g\u00f8r det hurtigere\u201c eller \u201eMangel p\u00e5 RAM \u2013 h\u00f8jere v\u00e6rdier holder processerne fri\u201c.<\/li>\n  <li><strong>\u00c6ndre trin for trin<\/strong>: \u00b120 til \u00b140 point. Der skal m\u00e5les mindst \u00e9n spidsfase pr. trin.<\/li>\n  <li><strong>Sammenlign<\/strong>: Jeg unders\u00f8ger, om SLO\u2019erne (f.eks. 95.-percentilen) bliver p\u00e5lideligt bedre, <em>uden<\/em> flere swap- eller OOM-h\u00e6ndelser.<\/li>\n  <li><strong>Rollback-kriterium<\/strong>: Hvis 95.\/99.-latenserne stiger, IO-ventetiderne \u00f8ges eller cache-misserne bliver hyppigere, tager jeg et skridt tilbage.<\/li>\n  <li><strong>Freeze &amp; dokumentation<\/strong>: Noter den endelige v\u00e6rdi, datoen, belastningsvinduet og n\u00f8gletallene.<\/li>\n<\/ol>\n\n<pre><code># Hurtig test for kontrollerede m\u00e5levinduer (kun vedligeholdelse!)\n# F\u00f8r: Tag et \u00f8jebliksbillede af n\u00f8gletallene\ndate; free -h; grep -E 'InodeCache|Cached' \/proc\/meminfo; vmstat 1 5\n\nsudo sysctl -w vm.vfs_cache_pressure=80\n# Afvent belastningstest\/spidsbelastning, registrer derefter n\u00f8gletallene igen og sammenlign\n<\/code><\/pre>\n\n<h2>Filsystemer og monteringsindstillinger: Konteksten er afg\u00f8rende<\/h2>\n\n<p>Effekten af vm.vfs_cache_pressure afh\u00e6nger ogs\u00e5 af filsystemet og monteringsindstillingerne. Jeg vurderer disse faktorer ud fra:<\/p>\n\n<ul>\n  <li><strong>relatime\/noatime<\/strong>: Forhindrer hyppige atime-skrivninger. noatime mindsker IO-belastningen ved mange l\u00e6sninger, hvilket g\u00f8r fordelene ved metadata mere tydelige.<\/li>\n  <li><strong>dovenskab<\/strong>: Forsinker opdateringer af metadata i RAM; dette udj\u00e6vner spidser, men p\u00e5virker tidspunktet for t\u00f8mning.<\/li>\n  <li><strong>ext4 vs. XFS vs. Btrfs<\/strong>: Forskellige inode-strukturer og Shrinker-adf\u00e6rd. Jeg m\u00e5ler altid <em>p\u00e5 m\u00e5l-FS\u2019en<\/em>, i stedet for at overf\u00f8re antagelser.<\/li>\n  <li><strong>NFS\/Net-FS<\/strong>: Caching og ugyldigg\u00f8relse af attributter kan begr\u00e6nse fordelene ved VFS. Aggressiv frigivelse (h\u00f8je v\u00e6rdier) medf\u00f8rer i s\u00e5 fald en stigning i antallet af fjernopslag.<\/li>\n  <li><strong>OverlayFS\/FUSE<\/strong>: Mange sm\u00e5 metadataprocesser drager stor fordel af VFS-cachen; jeg holder v\u00e6rdierne p\u00e5 et ret moderat til lavt niveau, s\u00e5 l\u00e6nge der er RAM til r\u00e5dighed.<\/li>\n<\/ul>\n\n<h2>Aspekter vedr\u00f8rende containere og cgroups<\/h2>\n\n<p>I container-milj\u00f8er husker jeg altid, at vm.vfs_cache_pressure er en <strong>p\u00e5 tv\u00e6rs af v\u00e6rter<\/strong> Knapper. \u00c6ndringerne vedr\u00f8rer <em>alle<\/em> Pods\/containere p\u00e5 noden. Derfor v\u00e6lger jeg en forsigtig tilgang og koordinerer optimeringen p\u00e5 node-niveau.<\/p>\n\n<ul>\n  <li><strong>Lagringsgr\u00e6nser<\/strong>: Memory-Cgroups begr\u00e6nser proces- og sidecache; slab-hukommelse kan medregnes proportionalt. Jeg observerer Pod-OOM\u2019er og Node-Pressure-h\u00e6ndelser i denne sammenh\u00e6ng.<\/li>\n  <li><strong>Arbejdsbyrdens sammens\u00e6tning<\/strong>: Knudepunkter, der k\u00f8rer b\u00e5de DB-pods og web-frontends, f\u00e5r ingen ekstreme v\u00e6rdier. Hvis det er n\u00f8dvendigt, fordeler jeg rollerne p\u00e5 forskellige knudepunkter.<\/li>\n  <li><strong>Udrulning<\/strong>: F\u00f8rst Canaries (en node), derefter gradvis udrulning. Jeg dokumenterer \u00e6ndringerne i node-baseline (sysctl.d) og noterer de ber\u00f8rte deployments.<\/li>\n<\/ul>\n\n<h2>S\u00e6rlige tilf\u00e6lde fra praksis<\/h2>\n\n<p>Nogle m\u00f8nstre kan man m\u00e5lrettet tackle, hvis jeg kender \u00e5rsagerne:<\/p>\n\n<ul>\n  <li><strong>CI\/Build-opgaver<\/strong>: Mange korte filadgange og katalogscanninger drager fordel af lavere v\u00e6rdier. Jeg h\u00e6ver dem igen, n\u00e5r jobbet er afsluttet, hvis der anvendes blandede noder.<\/li>\n  <li><strong>Vinduet \u00bbBackup\/Scan\u00ab<\/strong>: Lange kataloggenneml\u00f8b overskriver cachen. Midlertidigt kan en <em>h\u00f8jere<\/em> V\u00e6rdien (f.eks. 180) forhindrer under sikkerhedskopieringen, at dentries\/inodes fylder RAM\u2019en \u2013 bagefter nulstiller jeg den.<\/li>\n  <li><strong>Negative indtastninger<\/strong>: Ikke-eksisterende filer (404) gemmes ogs\u00e5 i cachen. Web-workloads med hyppige fejladgang forsyninger opn\u00e5r m\u00e5lbare forbedringer, hvis VFS-cachen ikke t\u00f8mmes for aggressivt.<\/li>\n  <li><strong>Streaming\/sekventiel I\/O<\/strong>: Her er det sidecachen, der dominerer; for lave v\u00e6rdier giver ikke meget og optager un\u00f8digt RAM. Jeg holder mig t\u00e6t p\u00e5 100 eller lidt derover.<\/li>\n<\/ul>\n\n<pre><code># Eksempel: V\u00e6r lidt mere aggressiv under en fuld sikkerhedskopiering\nsudo sysctl -w vm.vfs_cache_pressure=180\n# Efter sikkerhedskopieringen skal den tidligere fastlagte optimale v\u00e6rdi genindstilles\nsudo sysctl -w vm.vfs_cache_pressure=60\n<\/code><\/pre>\n\n<h2>Automatisering og styring<\/h2>\n\n<p>Efter vellykkede test integrerer jeg indstillingen i mine standard-builds. Det er vigtigt, at teams ved, <em>hvorfor<\/em> der er valgt en v\u00e6rdi, og <em>n\u00e5r<\/em> der skal kontrolleres (f.eks. efter \u00e6ndringer af version eller arbejdsbelastning).<\/p>\n\n<ul>\n  <li><strong>Konfigurationsstyring<\/strong>: Jeg definerer standardindstillinger for hver rolle (web, database, filserver) i \/etc\/sysctl.d\/ og distribuerer dem centralt.<\/li>\n  <li><strong>Driftkontrol<\/strong>: Der foretages regelm\u00e6ssige revisioner for at kontrollere, om live-v\u00e6rdierne og repositoryet stemmer overens.<\/li>\n  <li><strong>L\u00f8beb\u00f8ger<\/strong>: Jeg dokumenterer m\u00e5leprocedurer, gr\u00e6nsev\u00e6rdier for rollback og n\u00f8dprocedurer (f.eks. nulstilling til 100).<\/li>\n<\/ul>\n\n<pre><code>#-rolle: Webserver (eksempel)\ncat &lt;&lt;&#039;EOF&#039; | sudo tee \/etc\/sysctl.d\/50-web-vfs.conf\nvm.vfs_cache_pressure = 60\nEOF\nsudo sysctl --system\n<\/code><\/pre>\n\n<h2>vm.vfs_cache_pressure og andre kerneparametre<\/h2>\n\n<p>Et godt resultat opn\u00e5s f\u00f8rst i samspil med <strong>vm.swappiness<\/strong> og t\u00e6rskelv\u00e6rdierne for \u00bbdirty pages\u00ab. En lavere \u00bbswappiness\u00ab (f.eks. 10\u201320) holder processerne i RAM\u2019en i h\u00f8jere grad og undg\u00e5r un\u00f8dvendig udlagring. Med vm.dirty_background_ratio og vm.dirty_ratio regulerer jeg, hvor tidligt systemet skriver \u00e6ndrede sider v\u00e6k, s\u00e5 skrivespidsbelastninger ikke blokerer det hele. Jeg tilpasser disse v\u00e6rdier, s\u00e5 metadata-opslag forbliver hurtige, og skriveoperationer forl\u00f8ber planlagt. Her bruger jeg en overskuelig oversigt over samspillet mellem filcacher: <a href=\"https:\/\/webhosting.de\/da\/filsystem-caching-linux-side-cache-cacheboost\/\">Oversigt over filsystem-caching<\/a>.<\/p>\n\n<h2>Anbefalinger til hostingmilj\u00f8er og WordPress<\/h2>\n\n<p>Mange temaer, plugins og mediefiler genererer utallige sm\u00e5 filer, hvorfor en kraftig <strong>VFS-cache<\/strong> hj\u00e6lper m\u00e6rkbart. Jeg starter med 100, s\u00e6nker til 80, hvis der er tilstr\u00e6kkelig RAM, senere til 60, og tjekker responstider, 95. percentil for latenstider og CPU-steal. Hvis hukommelsen stadig er tilstr\u00e6kkelig, tester jeg 50 og validerer igen i aftenens spidsbelastning eller under kampagner. Hvis latenstiderne falder, uden at swap eller OOM-killer tr\u00e6der i kraft, fastl\u00e6gger jeg indstillingen permanent. Parallelt holder jeg \u00f8je med sidecachen, s\u00e5 de to cacher supplerer hinanden p\u00e5 en fornuftig m\u00e5de.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-cache-optimierung-7834.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sammenfatning<\/h2>\n\n<p>Med vm.vfs_cache_pressure styrer jeg <strong>Balance<\/strong> mellem hurtige metadatas\u00f8gninger og ledig RAM p\u00e5 en meget m\u00e5lrettet m\u00e5de. Til webrelaterede arbejdsbelastninger s\u00e6nker jeg v\u00e6rdien moderat, mens jeg h\u00e6ver den for applikationer, der kr\u00e6ver meget hukommelse. Hver \u00e6ndring underbygger jeg med m\u00e5lev\u00e6rdier for IO-latenser, cache-hits og swap-aktivitet. I kombination med vm.swappiness og dirty-parametrene opn\u00e5r jeg en stabil hukommelsesstyring. P\u00e5 den m\u00e5de udnytter jeg Linux-filsystemcachen effektivt og holder responstiderne p\u00e5lideligt lave under belastning.<\/p>","protected":false},"excerpt":{"rendered":"<p>Find ud af, hvordan du med \u00bbvm.vfs_cache_pressure\u00ab som fokusn\u00f8gleord kan udnytte Linux-filsystemets cache optimalt, styre cachen m\u00e5lrettet og forbedre ydeevnen for dine server-workloads.<\/p>","protected":false},"author":1,"featured_media":20867,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20874","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"139","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"vm.vfs_cache_pressure","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20867","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20874","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=20874"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20874\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/20867"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=20874"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=20874"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=20874"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}