{"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-cachebelasting-linux-bestandssysteem-cache-afstemming-optimalisatie","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/vm-vfs-cache-pressure-linux-filesystem-cache-tuning-optimierung\/","title":{"rendered":"vm.vfs_cache_pressure uitgelegd \u2013 Optimaal gebruikmaken van de cache van het Linux-bestandssysteem"},"content":{"rendered":"<p>Ik laat zien hoe de kernelparameter <strong>vm.vfs_cache_druk<\/strong> hoe de VFS-cache ten opzichte van de paginacache wordt gewogen en welke waarden bij een re\u00ebel belastingsprofiel voor meer snelheid zorgen. Met duidelijke stappen pas ik deze instelling aan, meet ik de effecten en maak ik zo gebruik van de <strong>Bestandssysteemcache<\/strong> optimaal.<\/p>\n\n<h2>Centrale punten<\/h2>\n\n<p>Om snel aan de slag te kunnen, vat ik de belangrijkste aspecten van het tunen van de <strong>VFS-caches<\/strong> 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.<\/p>\n\n<ul>\n  <li><strong>Werkingsprincipe<\/strong>: Bepaalt hoe resoluut de kernel Dentries\/inodes vrijgeeft in vergelijking met de paginacache.<\/li>\n  <li><strong>Standaardinstelling<\/strong>: 100 betekent een evenwichtige correctie zonder voorkeursbehandeling.<\/li>\n  <li><strong>Lage waarden<\/strong>: 50\u201380 zorgen ervoor dat metadata langer in het RAM-geheugen blijven en versnellen het opzoeken van bestanden.<\/li>\n  <li><strong>Hoge waarden<\/strong>: 120\u2013200 maken VFS-caches sneller vrij en maken ruimte vrij voor processen.<\/li>\n  <li><strong>Praktijk<\/strong>: Stapsgewijs aanpassen, meten, documenteren \u2013 pas daarna verder aanpassen.<\/li>\n<\/ul>\n\n<p>Ik pas deze principes consequent toe om de juiste balans te vinden tussen <strong>Cache-hit rate<\/strong> 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.<\/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>Wat is vm.vfs_cache_pressure?<\/h2>\n\n<p>Deze parameter bepaalt hoe streng de kernel de <strong>VFS-cache<\/strong> 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 <strong>Zoeksnelheid<\/strong> en het beschikbare werkgeheugen op een zeer directe manier.<\/p>\n\n<h2>Hoe werkt de VFS-cache precies?<\/h2>\n\n<p>Het Virtual Filesystem vormt een gemeenschappelijke laag voor ext4, XFS, Btrfs en dergelijke en slaat <strong>Dentries<\/strong> 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 <a href=\"https:\/\/webhosting.de\/nl\/linux-paginacache-prestatieverbeteraar\/\">Page-Cache Performance Booster<\/a> als achtergrondkennis, zodat ik VFS en paginacache in de juiste context kan beoordelen.<\/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>Standaardwaarde en typische waardenbereiken<\/h2>\n\n<p>Op de meeste systemen is de waarde ingesteld op <strong>100<\/strong> 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\u00ebert 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\u201340 punten en meet ik het effect op <strong>IO-latentie<\/strong> en responstijden.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Waarde<\/th>\n      <th>Dat betekent<\/th>\n      <th>Wanneer gebruiken?<\/th>\n      <th>Risico\/Opmerking<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>&lt; 100 (bijv. 50\u201380)<\/td>\n      <td>De VFS-cache blijft langer in het RAM-geheugen<\/td>\n      <td>Veel kleine bestanden, veelvuldige opzoekingen<\/td>\n      <td>Meer RAM-toewijzing aan <strong>Metagegevens<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>100<\/td>\n      <td>Evenwichtige aanpassing<\/td>\n      <td>Een betrouwbare startwaarde voor metingen<\/td>\n      <td>Goed <strong>Basislijn<\/strong>-waarde<\/td>\n    <\/tr>\n    <tr>\n      <td>&gt; 100 (bijv. 120\u2013200)<\/td>\n      <td>VFS-cache wordt agressiever vrijgegeven<\/td>\n      <td>Weinig RAM, databases met eigen cache<\/td>\n      <td>Mogelijke opzoekvertraging<\/td>\n    <\/tr>\n    <tr>\n      <td>Extreem (0, &gt; 500)<\/td>\n      <td>Ingrijpende verschuivingen<\/td>\n      <td>Bijzondere gevallen, kort testen<\/td>\n      <td>Gevaar voor de stabiliteit en <strong>Prestaties<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>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.<\/p>\n\n<h2>Rol bij het opschonen van het geheugen<\/h2>\n\n<p>Onder druk moet de kernel RAM vrijgeven, en juist hier bepaalt vm.vfs_cache_pressure de afweging tussen <strong>VFS-cache<\/strong>, 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\u00ebn voor het vrijmaken van de paginacache geeft dit mij inzicht in <a href=\"https:\/\/webhosting.de\/nl\/server-pagina-cache-eviction-linux-geheugen-print-optimalisatie-inzicht\/\">Verwijdering uit de paginacache<\/a> waardevolle praktijkgerichte inzichten, zodat ik beslissingen op basis van feiten kan nemen.<\/p>\n\n<h2>Meetmethode: de VFS-cache transparant maken<\/h2>\n\n<p>Voordat ik iets verander, maak ik het zichtbaar, <strong>waarbij<\/strong> geheugen zit en <strong>wat<\/strong> wordt verdrongen. Zo kan ik vaststellen of metadata echt het knelpunt is \u2013 of dat de paginacache, processen of \u2018dirty pages\u2019 de overhand hebben.<\/p>\n\n<ul>\n  <li><strong>\/proc\/meminfo<\/strong>: Ik controleer InodeCache, Cached, Buffers, SReclaimable en SUnreclaim om het aandeel en de terugwinbaarheid in te schatten.<\/li>\n  <li><strong>plaattop<\/strong>: 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.<\/li>\n  <li><strong>IO-pad<\/strong>: Met vmstat\/iostat houd ik de leestijden in de gaten en kijk ik of het aantal schijftoegangen toeneemt bij lookups.<\/li>\n<\/ul>\n\n<pre><code># Snel overzicht\ngrep -E 'InodeCache|SReclaimable|SUnreclaim|Cached|Buffers' \/proc\/meminfo\n\n# Slab-verdeling (gesorteerd op grootte)\nsudo slabtop -s c\n\n# Alleen dentry\/inode-achtige slabs eruit filteren\ngrep -Ei 'dentry|inode' \/proc\/slabinfo | sort -k3 -nr | head\n\n# IO- en geheugentrends per seconde\nvmstat 1\niostat -x 1\n<\/code><\/pre>\n\n<p>Ik vind de interpretatie duidelijk: als SReclaimable samen met dentry\/inode-slabs groeit en tegelijkertijd de IO-latenties toenemen <em>niet<\/em>, 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.<\/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>Praktijk: de huidige waarde uitlezen en wijzigen<\/h2>\n\n<p>De controle kan via de opdrachtregel binnen enkele seconden worden uitgevoerd, zonder <strong>Herstart<\/strong>. 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.<\/p>\n\n<pre><code># Huidige waarde controleren\ncat \/proc\/sys\/vm\/vfs_cache_pressure\n# of\nsysctl vm.vfs_cache_pressure\n\n# Tijdelijk testen (tot de volgende herstart)\nsudo sysctl -w vm.vfs_cache_pressure=60\n# alternatief\necho 60 | sudo tee \/proc\/sys\/vm\/vfs_cache_pressure\n\n# Permanent instellen\necho \"vm.vfs_cache_pressure = 60\" | sudo tee -a \/etc\/sysctl.conf\nsudo sysctl -p\n<\/code><\/pre>\n\n<h2>Linux-cache-optimalisatie: zinvolle scenario\u2019s<\/h2>\n\n<p>Bij hostingplatforms met veel statische bestanden, bestandsopslagplaatsen of applicaties met een eigen buffer loont het de moeite om gericht <strong>weging<\/strong> 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.<\/p>\n\n<h3>Webserver met veel statische bestanden<\/h3>\n<p>Voor CSS, JS en afbeeldingen bewaar ik de metagegevens graag wat langer in de <strong>Cache<\/strong>. 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.<\/p>\n\n<h3>Bestandsservers of NAS-systemen<\/h3>\n<p>Veel gebruikersbezoeken en mapwisselingen profiteren van <strong>lagere<\/strong> tot evenwichtige waarden. Als er voldoende RAM beschikbaar is, neig ik eerder naar 50\u201380; 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.<\/p>\n\n<h3>Databaseservers en systemen met weinig geheugen<\/h3>\n<p>Databases hebben een eigen buffer-cache, daarom geef ik de <strong>Procesgeheugen<\/strong> 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.<\/p>\n\n<h2>Voorbeelden van werkbelasting en richtwaarden<\/h2>\n\n<p>Ik begin met 100 en verlaag het in stappen van 20 voor webgerichte <strong>Werklasten<\/strong> en verhoog ik in stappen van 20 voor processen die veel geheugen verbruiken. Ik test elk niveau gedurende ten minste \u00e9\u00e9n 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 <a href=\"https:\/\/webhosting.de\/nl\/linux-paginacache-prestatieverbeteraar\/\">Page-Cache Performance Booster<\/a> aanvullende achtergrondinformatie over bestandscache-strategie\u00ebn, 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.<\/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>Risico's en valkuilen<\/h2>\n\n<p>Als ik de waarde te laag instel, kan de kernel VFS-vermeldingen nauwelijks vrijmaken, wat bij pieken tot <strong>OOM<\/strong>\u2011risico\u2019s 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\u00eble 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.<\/p>\n\n<h2>Monitoring en meetgrootheden<\/h2>\n\n<p>Of een aanpassing de moeite waard is, blijkt uit harde <strong>Metriek<\/strong>. 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 \u2018time-to-first-byte\u2019 op. Als de IO-latentie laag blijft en het swappen afneemt, bevestigt dat de koers.<\/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: van hypothese tot betrouwbare instelling<\/h2>\n\n<p>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.<\/p>\n\n<ol>\n  <li><strong>Uitgangssituatie vastleggen<\/strong>: vm.vfs_cache_pressure=100, 24\u201372 uur realistische belasting. Kerncijfers vastleggen (latenties: mediaan\/95e\/99e percentiel, IO-wachttijd, CPU-steal, swap-activiteit, inode\/dentry-grootte).<\/li>\n  <li><strong>Een hypothese formuleren<\/strong>: \u201eVeel kleine bestanden, lookups zijn duur \u2013 lagere waarden versnellen het proces\u201c of \u201eWeinig RAM \u2013 hogere waarden houden processen vrij\u201c.<\/li>\n  <li><strong>Stapsgewijs wijzigen<\/strong>: \u00b120 tot \u00b140 punten. Meet per niveau ten minste \u00e9\u00e9n piekfase.<\/li>\n  <li><strong>Vergelijken<\/strong>: Ik ga na of de SLO's (bijvoorbeeld het 95e percentiel) betrouwbaar verbeteren, <em>zonder<\/em> meer swap- of OOM-gebeurtenissen.<\/li>\n  <li><strong>Rollback-criterium<\/strong>: Als de 95e\/99e-latentie toeneemt, de IO-wachttijden langer worden of er steeds vaker cache-misses optreden, doe ik een stap terug.<\/li>\n  <li><strong>Freeze &amp; documentatie<\/strong>: De eindwaarde, datum, belastingsvenster en kengetallen vastleggen.<\/li>\n<\/ol>\n\n<pre><code># Korte test voor gecontroleerde meetvensters (alleen onderhoud!)\n# Vooraf: momentopname van kengetallen maken\ndate; free -h; grep -E 'InodeCache|Cached' \/proc\/meminfo; vmstat 1 5\n\nsudo sysctl -w vm.vfs_cache_pressure=80\n# Belastingstest\/piek afwachten, daarna opnieuw statistieken vastleggen en vergelijken\n<\/code><\/pre>\n\n<h2>Bestandssystemen en mount-opties: de context is belangrijk<\/h2>\n\n<p>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:<\/p>\n\n<ul>\n  <li><strong>relatijd\/geen-tijd<\/strong>: Voorkomt veelvuldige atime-schrijfbewerkingen. noatime vermindert de IO-belasting bij veel leesbewerkingen, waardoor de voordelen van metadata beter zichtbaar worden.<\/li>\n  <li><strong>luiheid<\/strong>: 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.<\/li>\n  <li><strong>ext4 versus XFS versus Btrfs<\/strong>: Verschillende inode-structuren en het gedrag van de shrinker. Ik meet altijd <em>op de doel-FS<\/em>, in plaats van aannames over te nemen.<\/li>\n  <li><strong>NFS\/Netwerk-FS<\/strong>: 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.<\/li>\n  <li><strong>OverlayFS\/FUSE<\/strong>: Veel kleine metadataprocessen hebben veel baat bij de VFS-cache; ik houd de waarden eerder gematigd tot laag, mits er voldoende RAM beschikbaar is.<\/li>\n<\/ul>\n\n<h2>Aspecten met betrekking tot containers en cgroups<\/h2>\n\n<p>In containeromgevingen houd ik het volgende in gedachten: vm.vfs_cache_pressure is een <strong>op het hele hostniveau<\/strong> Schakelaar. De wijzigingen hebben betrekking op <em>alle<\/em> Pods\/containers op het knooppunt. Ik hanteer daarom een voorzichtige aanpak en co\u00f6rdineer de afstemming op knooppuntniveau.<\/p>\n\n<ul>\n  <li><strong>Opslaglimieten<\/strong>: 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\u2019s en node-pressure-gebeurtenissen.<\/li>\n  <li><strong>Workload-mix<\/strong>: Knooppunten die zowel DB-pods als web-frontends bevatten, krijgen geen extreme waarden. Indien nodig verdeel ik de rollen over verschillende knooppunten.<\/li>\n  <li><strong>Uitrol<\/strong>: Eerst Canaries (\u00e9\u00e9n node), daarna gefaseerd uitrollen. Ik documenteer de wijzigingen in de node-baseline (sysctl.d) en noteer de betrokken deployments.<\/li>\n<\/ul>\n\n<h2>Speciale gevallen uit de praktijk<\/h2>\n\n<p>Sommige patronen kunnen gericht worden aangepakt als ik de oorzaken ken:<\/p>\n\n<ul>\n  <li><strong>CI\/Build-taken<\/strong>: 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.<\/li>\n  <li><strong>Venster 'Back-up\/Scan'<\/strong>: Lange mapdoorlopen wissen de cache. Tijdelijk kan een <em>hoger<\/em> Waarde (bijv. 180) om tijdens de back-up te voorkomen dat dentries\/inodes het RAM-geheugen volmaken \u2013 daarna zet ik de waarde weer terug.<\/li>\n  <li><strong>Negatieve Dentries<\/strong>: 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.<\/li>\n  <li><strong>Streaming\/Sequenti\u00eble I\/O<\/strong>: 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.<\/li>\n<\/ul>\n\n<pre><code># Voorbeeld: tijdens een volledige back-up iets agressiever te werk gaan\nsudo sysctl -w vm.vfs_cache_pressure=180\n# Na de back-up weer terug naar de eerder vastgestelde optimale waarde\nsudo sysctl -w vm.vfs_cache_pressure=60\n<\/code><\/pre>\n\n<h2>Automatisering en governance<\/h2>\n\n<p>Na succesvolle tests neem ik de instelling op in mijn standaardbuilds. Het is belangrijk dat teams weten dat, <em>waarom<\/em> er een waarde is gekozen en <em>wanneer<\/em> dit moet worden gecontroleerd (bijvoorbeeld na een wijziging van de versie of de workload).<\/p>\n\n<ul>\n  <li><strong>Configuratiebeheer<\/strong>: Ik stel per rol (web, database, bestandsserver) standaardinstellingen in \/etc\/sysctl.d\/ in en verspreid deze centraal.<\/li>\n  <li><strong>Driftcontrole<\/strong>: Er worden regelmatig audits uitgevoerd om te controleren of de live-waarden en de repository met elkaar overeenkomen.<\/li>\n  <li><strong>Hardloopboeken<\/strong>: Ik leg meetstappen, drempelwaarden voor rollback en noodprocedures (bijv. terugzetten naar 100) vast.<\/li>\n<\/ul>\n\n<pre><code>#-rol: webserver (voorbeeld)\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 en andere kernelparameters<\/h2>\n\n<p>Een goed resultaat ontstaat pas in samenspel met <strong>vm.swappiness<\/strong> en de drempelwaarden voor dirty pages. Een lagere swappiness (bijv. 10\u201320) 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\u2019s 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: <a href=\"https:\/\/webhosting.de\/nl\/bestandssysteem-caching-linux-paginacache-cacheboost\/\">Overzicht van bestandssysteemcaching<\/a>.<\/p>\n\n<h2>Aanbevelingen voor hostingomgevingen en WordPress<\/h2>\n\n<p>Veel thema\u2019s, plug-ins en media genereren talloze kleine bestanden, en daarom is een krachtige <strong>VFS-cache<\/strong> 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.<\/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>Samenvatting<\/h2>\n\n<p>Met vm.vfs_cache_pressure regel ik de <strong>Saldo<\/strong> 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\u00ebnt gebruik van de Linux-bestandssysteemcache en houd ik de responstijden onder belasting betrouwbaar laag.<\/p>","protected":false},"excerpt":{"rendered":"<p>Ontdek hoe je met \u2018vm.vfs_cache_pressure\u2019 als trefwoord optimaal gebruik kunt maken van de Linux-bestandssysteemcache, caches doelgericht kunt beheren en de prestaties van je serverworkloads kunt verbeteren.<\/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":"136","_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\/nl\/wp-json\/wp\/v2\/posts\/20874","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=20874"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/20874\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/20867"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=20874"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=20874"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=20874"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}