{"id":20540,"date":"2026-08-11T11:56:13","date_gmt":"2026-08-11T09:56:13","guid":{"rendered":"https:\/\/webhosting.de\/linux-page-cache-performance-booster\/"},"modified":"2026-08-11T11:56:13","modified_gmt":"2026-08-11T09:56:13","slug":"linux-paginacache-prestatieverbeteraar","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/linux-page-cache-performance-booster\/","title":{"rendered":"De Linux-paginacache begrijpen: betere prestaties dankzij de cache"},"content":{"rendered":"<p><strong>Linux-pagina<\/strong> Ik beschouw de cache als een direct middel om sneller toegang te krijgen tot bestanden, omdat deze herhaalde leesbewerkingen vanuit het RAM-geheugen afhandelt in plaats van vanuit tragere opslagmedia. Ik laat concreet zien hoe de kernel hierdoor de latentie vermindert, workloads zoals webservers, databases en WordPress versnelt, en hoe ik met eenvoudige middelen van dit effect profiteer.<\/p>\n\n<h2>Centrale punten<\/h2>\n\n<p>De volgende kernpunten helpen mij om de <strong>Pagina cache<\/strong> te beoordelen en doelgericht in te zetten.<\/p>\n<ul>\n  <li><strong>RAM-cache<\/strong>: Bestandsgegevens worden in het geheugen opgeslagen, waardoor de toegangstijd wordt verkort.<\/li>\n  <li><strong>Terugboeking<\/strong>: Schrijfbewerkingen worden effici\u00ebnter gebundeld als \u201edirty pages\u201c.<\/li>\n  <li><strong>Transparantie<\/strong>: Toepassingen profiteren hiervan zonder dat er wijzigingen in de code nodig zijn.<\/li>\n  <li><strong>Dynamiek<\/strong>: De cache maakt geheugen vrij wanneer dat nodig is.<\/li>\n  <li><strong>Werklasten<\/strong>: Web, DB, CI\/CD en logs boeken merkbare vooruitgang.<\/li>\n<\/ul>\n\n<h2>Wat is de Linux-paginacache?<\/h2>\n\n<p>Ik begrijp de <strong>Pagina cache<\/strong> als opslaggebied in het RAM waarin de kernel bestandsblokken bewaart zodra processen via <code>read()<\/code>, <code>write()<\/code> of <code>mmap()<\/code> toegang krijgen tot bestanden. Bij elke toegang controleert de kernel eerst de cache en levert gegevens onmiddellijk vanuit het geheugen als ze al aanwezig zijn, wat de reactietijd meetbaar verkort. Als gegevens niet in de cache worden aangetroffen, laadt de kernel ze vanaf de opslagmedia, slaat ze daar op en stelt ze ter beschikking aan het proces, waardoor bij de volgende toegang een snelle hit ontstaat. Dit mechanisme hangt nauw samen met het Virtual File System en verloopt transparant voor applicaties, waardoor het universeel inzetbaar is. Uit deze werkwijze volgt een eenvoudig principe: ik gebruik vrij RAM als <strong>Cache-ruimte<\/strong> in plaats van hem ongebruikt te laten liggen.<\/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-page-cache-performance-5830.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Waarom de paginacache voor een merkbare versnelling zorgt<\/h2>\n\n<p>Het grootste effect ontstaat doordat ik <strong>Schijf-I\/O<\/strong> drastisch verminderen zodra terugkerende gegevens in de cache staan en niet opnieuw van het opslagmedium hoeven te worden gelezen. Leesbewerkingen maken dan gebruik van het RAM-geheugen, wat de latentie en wachtrijen bij de controllers aanzienlijk vermindert. Ook schrijfprocessen profiteren hiervan, omdat de kernel wijzigingen markeert als \u201edirty pages\u201c, deze in de tijd bundelt en later effici\u00ebnt naar het opslagmedium schrijft. Zo verdwijnen veel kleine afzonderlijke toegangen, die de opslag zouden belasten, ten gunste van minder, maar grotere bewerkingen. Al met al voelt een systeem na een korte opwarmfase sneller aan, omdat er meer werkgegevens in de <strong>Geheugen<\/strong> blijven.<\/p>\n\n<h2>Lezen, schrijven, Dirty Pages: zo gaat het in zijn werk<\/h2>\n\n<p>Een leesbewerking begint altijd met een cachecontrole, waardoor ik hits zonder wachttijd krijg en misses slechts \u00e9\u00e9n keer kosten. Bij het schrijven komt de gewijzigde inhoud eerst in het RAM terecht en wordt deze als \u201edirty\u201c in de wachtrij geplaatst, totdat de kernel deze in \u00e9\u00e9n keer naar de opslagmedia overbrengt. Indien gewenst forceer ik de permanente opslag met <code>fsync()<\/code>, wat belangrijk blijft wanneer gegevens <strong>Consistentie<\/strong> onmiddellijk nodig hebben. Dit write-back-traject verhoogt de effici\u00ebntie van toepassingen die met veel kleine bestanden werken, zoals PHP-code, configuratiebestanden of assets. Tegelijkertijd houd ik in het oog dat write-back weliswaar prestatievoordelen oplevert, maar dat er een korte periode is waarin nog niet alles fysiek is opgeslagen.<\/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_Page_Cache_3892.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Beschikbaar RAM is cache \u2013 geen verlies<\/h2>\n\n<p>Velen staan sceptisch tegenover \u201ebezette\u201c opslagruimte, maar ik interpreteer de waarde correct door het aandeel \u201ebuff\/cache\u201c als een zinvolle <strong>tijdelijke opslag<\/strong> waarden. De kernel maakt actief gebruik van ongebruikt RAM, geeft dit indien nodig razendsnel terug aan processen en regelt het evenwicht via reclaim-mechanismen. Deze dynamiek zorgt ervoor dat mijn systeem snel reageert, zolang er voldoende werkgeheugen in de cache aanwezig is. Als de behoefte van een toepassing toeneemt, verdringt de kernel oude cachepagina\u2019s en maakt ruimte vrij, zonder dat ik handmatig hoef in te grijpen. Als ik in periodes van hoge belasting terechtkom, let ik daarbij vooral op <a href=\"https:\/\/webhosting.de\/nl\/geheugendruk-linux-kernel-hosting-systemen-optimalisatie-ram\/\">Opslagdruk<\/a>, om de situatie correct te beoordelen en knelpunten in kaart te brengen.<\/p>\n\n<h2>Workloads die hier sterk van profiteren<\/h2>\n\n<p>Ik zie de grootste voordelen op alle plaatsen waar gegevens vaak terugkomen en er veel kleine toegangen plaatsvinden, die de <strong>Cache<\/strong> vereenvoudigd. Klassieke voorbeelden zijn webservers met veelgebruikte PHP- en HTML-bestanden, evenals WordPress-installaties met terugkerende thema\u2019s, plug-ins, media en configuraties. Databases profiteren bij herhaalde query\u2019s op bestandssysteemniveau, mits ze de paginacache niet doelbewust omzeilen. CI\/CD-systemen met build-artefacten en tools die veel kleine bestanden verwerken, worden eveneens merkbaar sneller. Zelfs logboekanalyses die sequentieel lezen, krijgen een voorsprong dankzij RAM-buffers, omdat de kernel toegangspatronen bijhoudt en deze sneller ter beschikking stelt.<\/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-page-cache-performance-3829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoring en metingen: zo beoordeel ik cache-effecten<\/h2>\n\n<p>Ik controleer eerst met <code>vrij -h<\/code>, hoe groot \u201ebuff\/cache\u201c is en hoe <strong>bezet<\/strong> Geheugen dat zich in de loop van de tijd heeft ontwikkeld. Een blik op <code>\/proc\/meminfo<\/code> toont mij kengetallen zoals <code>In cache opgeslagen<\/code>, <code>Vies<\/code> en <code>Writeback<\/code>, die informatie geven over populaire artikelen en nog af te ronden schrijfopdrachten. Met <code>iostat -x 1<\/code> of <code>pidstat -d 1<\/code> merk ik of de fysieke I\/O-belasting afneemt zodra mijn cache is opgewarmd. Tools zoals <code>perf<\/code> of <code>bcc<\/code>-gebaseerde scripts helpen om diepgang te cre\u00ebren, maar zijn in de dagelijkse praktijk zelden nodig als er duidelijke patronen zichtbaar zijn. Daarnaast test ik door herhaaldelijk bestanden te openen of de tweede run aanzienlijk sneller verloopt, wat het effect van de <strong>Caches<\/strong> bevestigd.<\/p>\n\n<h2>Tuning: parameters en zinvolle standaardinstellingen<\/h2>\n\n<p>Ik pas alleen aan wat ik begrijp, en begin bij het afstemmen van de cache met een paar, goed te begrijpen <strong>Stelschroeven<\/strong>. De vm.dirty-parameters bepalen vanaf wanneer schrijfbewerkingen van het RAM-geheugen naar het opslagmedium worden doorgestuurd en hoe intensief dit proces verloopt. <code>vm.vfs_cache_druk<\/code> bepaalt in hoeverre de kernel de Dentry- en Inode-caches overschrijft, wat direct van invloed is op bestandssysteemoperaties. Readahead-waarden op blokapparaatniveau kunnen de sequenti\u00eble leesprestaties verbeteren als workloads hier baat bij hebben. Ik documenteer elke stap, test onder belasting en keer indien nodig terug naar de standaardwaarden als er geen winst wordt geboekt.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Parameters<\/strong><\/th>\n      <th><strong>Standaard<\/strong><\/th>\n      <th><strong>Effect<\/strong><\/th>\n      <th><strong>Wanneer wijzigen<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>vm.vuile_achtergrond_verhouding<\/td>\n      <td>10%<\/td>\n      <td>Start van de asynchrone write-back-fase<\/td>\n      <td>Bij veel kleine schrijfbewerkingen eerder laten overstromen<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_ratio<\/td>\n      <td>20%<\/td>\n      <td>Maximaal aandeel \u201edirty\u201c in het RAM-geheugen<\/td>\n      <td>Bij piekbelasting meer buffer toestaan<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_expire_centisecs<\/td>\n      <td>3000<\/td>\n      <td>Veroudering \u201edirty\u201c tot aan de flush (in 1\/100 s)<\/td>\n      <td>Bij latentiedoelen: instellen op een jongere leeftijd<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_writeback_centiseconden<\/td>\n      <td>500<\/td>\n      <td>Interval voor write-back op de achtergrond<\/td>\n      <td>Bij trage opslag de belasting iets verhogen<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.vfs_cache_druk<\/td>\n      <td>100<\/td>\n      <td>Behoefte om dentries\/inodes op te ruimen<\/td>\n      <td>Bij veel bestandsbewerkingen verminderen<\/td>\n    <\/tr>\n    <tr>\n      <td>Block-Readahead<\/td>\n      <td>afhankelijk van het apparaat<\/td>\n      <td>Sequentieel leesvoorbeeld<\/td>\n      <td>Bij streaming-reads verhogen<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Voor meer inzicht in de processen bij terugwinning en opslag is het de moeite waard om eens te kijken naar <a href=\"https:\/\/webhosting.de\/nl\/server-pagina-cache-eviction-linux-geheugen-print-optimalisatie-inzicht\/\">Verwijdering uit de paginacache<\/a>, om de eigen opstelling goed te kunnen beoordelen. Ik breng wijzigingen altijd stapsgewijs aan, houd de resultaten bij aan de hand van meetpunten en leg de effecten duidelijk vast, zodat elke <strong>Aanpassing<\/strong> begrijpelijk blijft.<\/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\/LinuxCachePerformance5678.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Paginacache en databases: wanneer is het zinvol om deze te omzeilen?<\/h2>\n\n<p>Sommige databases maken bewust gebruik van <strong>Directe I\/O<\/strong> om dubbele buffering te voorkomen en hun eigen caches te gebruiken. In dergelijke scenario\u2019s werk ik met de interne parameters van de database en vertrouw ik minder op de Linux-paginacache. Als een engine vaak nieuwe gegevens of zeer grote hoeveelheden gegevens opvraagt, loont het om het bypass-model te gebruiken om het geheugengebruik beter te kunnen plannen. Ligt de focus daarentegen op herhaaldelijk lezen van bestanden uit dezelfde tabellen of indexen, dan blijft de bestandssysteemcache nuttig. Ik baseer mijn beslissing op het daadwerkelijke toegangs patroon, niet op een algemene regel, zodat de <strong>Prestaties<\/strong> echt stijgt.<\/p>\n\n<h2>Eviction, Reclaim en geheugendruk<\/h2>\n\n<p>Bij hoge belasting sorteert de kernel pagina\u2019s in actieve en inactieve pagina\u2019s <strong>LRU-lijsten<\/strong> en verwijdert kandidaten stapsgewijs uit de cache. Dit \u2018reclaim\u2019-proces reageert op druk die ontstaat door toenemende procesvraag, cgroup-limieten of I\/O-wachttijden. Als mijn monitoring meer verwijderingen en tegelijkertijd een stijgende I\/O-belasting signaleert, weet ik dat de werkdataset groter is dan het beschikbare RAM-geheugen. In dergelijke situaties beoordeel ik of ik workloads moet isoleren, caching-strategie\u00ebn moet aanpassen of het geheugen moet uitbreiden. Om de verwijderingsregels beter te begrijpen, helpt een gestructureerde handleiding over <a href=\"https:\/\/webhosting.de\/nl\/geheugendruk-linux-kernel-hosting-systemen-optimalisatie-ram\/\">Opslagdruk<\/a>, om symptomen correct te interpreteren en maatregelen te plannen.<\/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_performance_8372.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praktijk: snelle controles en opdrachten<\/h2>\n\n<p>Om een eerste indruk te geven, begin ik met <code>vrij -h<\/code> en bekijk het aandeel <strong>buffer\/cache<\/strong>, voordat ik er dieper op inga. Daarna vergelijk ik twee doorlopen van een bestandsscan, bijvoorbeeld met <code>vinden<\/code> of een benchmark, en bekijk het tijdsverschil tussen een koude en een warme start. <code>grep -E \"Cached|Dirty|Writeback\" \/proc\/meminfo<\/code> laat me zien hoeveel er in de cache staat en wat er nog moet worden geschreven. <code>iostat -xz 1<\/code> laat zien hoe druk de apparaten het hebben en of de wachtrij afneemt zodra de cache in werking treedt. Wie meer wil weten over de basisprincipes van caching, vindt in het overzicht over <a href=\"https:\/\/webhosting.de\/nl\/bestandssysteem-caching-linux-paginacache-cacheboost\/\">Caching van het bestandssysteem<\/a> een toegankelijke inleiding die de wisselwerking tussen VFS en het RAM-buffergeheugen uitlegt.<\/p>\n\n<h2>Veelvoorkomende misverstanden uit de weg ruimen<\/h2>\n\n<p>\u201eHet RAM-geheugen is vol, de server heeft een probleem\u201c, hoor ik vaak, maar de <strong>Cache<\/strong> Dit is het antwoord, niet de oorzaak. Linux maakt werkgeheugen flexibel vrij wanneer applicaties het gebruiken, en neemt het weer in beslag zodra er nieuwe gegevens tijdelijk worden opgeslagen. Het handmatig leegmaken via <code>echo 3 &gt; \/proc\/sys\/vm\/drop_caches<\/code> levert zelden blijvend voordeel op en vertekent de meetresultaten. Het is zinvoller om echte knelpunten te identificeren en de I\/O-paden daar te ontlasten. Ik maak bovendien onderscheid tussen de paginacache en de slab-caches voor dentries\/inodes, zodat ik niet twee verschillende <strong>Mechanismen<\/strong> in een pan doe.<\/p>\n\n<h2>Mount-opties en nuances van bestandssystemen<\/h2>\n\n<p>Ik houd er rekening mee dat bestandssysteem- en mount-opties de effici\u00ebntie van de paginacache sterk be\u00efnvloeden. <strong>atijd<\/strong>-Updates zorgen voor extra schrijfbewerkingen; met <em>relatime<\/em> (tegenwoordig standaard) verminder ik deze, <em>noatime<\/em> bespaart nog meer als ik nooit afhankelijk ben van openingstijden. <strong>sync<\/strong> en <strong>dirsync<\/strong> zorgen voor onmiddellijke persistentie en doen afbreuk aan de voordelen van write-back \u2013 gerechtvaardigd voor metadata waarbij latentie cruciaal is, maar verder vermijd ik ze. Journaling-modi (bijv. bij ext4 <em>data=geordend<\/em> vs. <em>terugschrijven<\/em>) bepalen of gebruiksgegevens v\u00f3\u00f3r of na de metagegevens op het medium worden opgeslagen; ik geef de voorkeur aan veiligheid boven schijnbare prestaties. XFS en btrfs gedragen zich anders wat betreft metagegevens en CoW: CoW, compressie of deduplicatie besparen I\/O, maar kunnen CPU-kracht kosten. Daarom meet ik de werklast op realistische wijze en beslis ik of de mount-opties aansluiten bij het toegangs patroon.<\/p>\n\n<h2>Containers, VM's en dubbele caches<\/h2>\n\n<p>In containers delen alle processen dezelfde kernel \u2013 en dus ook dezelfde paginacache. Dit vergemakkelijkt het delen van veelgebruikte bestanden (bijvoorbeeld bibliotheken), maar strenge cgroup-limieten (<em>geheugen.max<\/em>) kunnen cachepagina\u2019s vroegtijdig vervangen. Ik houd rekening met headroom per dienst en maak gebruik van <em>geheugen.laag<\/em>, om belangrijke caches wat bescherming te bieden. In VM\u2019s bestaan <strong>twee<\/strong> Caches: in de gast en eventueel bij de host (bij bestandsback-ups). Dit leidt tot dubbele buffering. Als ik raw-devices of Direct Storage gebruik, bespaar ik de host-cache, maar verlies ik de voordelen daarvan. Ballooning en overcommit be\u00efnvloeden de reclaim in de gast \u2013 ik houd in de gaten of voortdurende ballooning leidt tot cache-thrashing en pas de resources of de sizing aan. Bij containeropslag (OverlayFS) warm ik veelgebruikte lagen gericht op, zodat deployments niet koud opstarten.<\/p>\n\n<h2>NUMA, cgroups en isolatie<\/h2>\n\n<p>Op NUMA-systemen onderhoudt de kernel LRU-lijsten per node. Als threads voornamelijk lokaal toegang hebben, blijven de hits in de paginacache <strong>numa-nah<\/strong> en verminderen de latentie. Via CPU- en geheugenaffiniteit zorg ik ervoor dat een toepassing en haar gegevens dicht bij elkaar liggen. Via <strong>memcg<\/strong> (cgroups v2) wordt de paginacache aan een groep toegewezen; met <em>geheugen.hoog<\/em> activeer ik een gecontroleerde reclaim, met <em>geheugen.max<\/em> stel ik strikte grenzen en met <em>geheugen.laag<\/em> Ik geef prioriteit aan belangrijke diensten. Deze tools zorgen ervoor dat een luidruchtige batchtaak de cache van een latentiegevoelige webservice niet leegmaakt. Isolatie zorgt voor voorspelbaarheid \u2013 maar ik zorg voor een evenwicht, zodat er niet te veel kleine caches ontstaan die elk te weinig treffers opleveren.<\/p>\n\n<h2>SSD, HDD en readahead in de praktijk<\/h2>\n\n<p>Readahead is een voordeel bij sequenti\u00eble patronen, maar bij willekeurige toegangen vaak slechts ballast. Op HDD's verhoog ik readahead doorgaans om lineaire scans te versnellen. Op snelle NVMe-SSD's is het nut kleiner; te veel readahead verspilt RAM en verslechtert cache-hits, omdat ongebruikte pagina's andere verdringen. Ik pas readahead per apparaat aan en controleer door middel van herhaalde tests of de doorvoer of de latentie hierdoor verbeteren. Daarnaast let ik op de I\/O-scheduler: voor NVMe is \u201enone\u201c\/\u201emq-deadline\u201c gebruikelijk, terwijl HDD\u2019s baat kunnen hebben bij deadline-planning. De paginacache egaliseert de I\/O-profielen, maar de bloklaag moet hierop zijn afgestemd. Het doel blijft dat de cache voornamelijk nuttige, hergebruikte gegevens bevat \u2013 niet alleen vooraf opgehaalde bytes.<\/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-page-cache-performance-4827.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Koude opstarten, voorverwarmen en implementaties<\/h2>\n\n<p>Elke cache heeft een opwarmfase nodig. Na een herstart of rollout lees ik gericht hotsets in, bijvoorbeeld door belangrijke mappen eenmaal sequentieel te doorlopen. Dit verkort de \u201ekoude minuut\u201c na een implementatie merkbaar. Bij rolling-strategie\u00ebn houd ik ten minste \u00e9\u00e9n warme instantie online, zodat de totale dienst snel reageert terwijl nieuwe instanties hun cache vullen. Ik vermijd grootschalige wijzigingen in de bestandsboom (bijv. veranderende paden), omdat dit de dentries\/inodes 'koud' maakt. In plaats daarvan werk ik met atomaire symlink-switches of \u2018copy-on-write\u2019-strategie\u00ebn, waarbij bestandsinhoud en paden grotendeels stabiel blijven. Zo blijft niet alleen de paginacache effectief, maar blijven ook de metadatacaches hun werking behouden.<\/p>\n\n<h2>Meetgrootheden in de diepte<\/h2>\n\n<p>Naast <code>\/proc\/meminfo<\/code> voor een gedetailleerde diagnose neem ik een kijkje in <code>\/proc\/vmstat<\/code>: tellers zoals <em>pgfault<\/em> en <em>pgmajfault<\/em> maken onderscheid tussen lichte en ernstige page faults, <em>nr_active_file<\/em>\/<em>nr_inactive_file<\/em> geven de grootte van de op bestanden gebaseerde werkset weer, en <em>werkset_fout<\/em> helpt bij het herkennen van thrashing. Als het aantal refaults toeneemt terwijl de I\/O-snelheid van het apparaat hoog blijft, past de werk set niet in het RAM. Ik test met twee runs van dezelfde workload: de tweede run zou aanzienlijk sneller moeten zijn als de cache werkt. Voor reproduceerbare cold-start-tests leeg ik caches uitsluitend in de laboratoriumomgeving en documenteer ik dit zorgvuldig, om productiemetingen niet te vertekenen. Ik vind het belangrijk om niet \u00e9\u00e9n enkele indicator te overinterpreteren, maar patronen te herkennen in tijdreeksen.<\/p>\n\n<h2>Swap, swappiness en thrashing voorkomen<\/h2>\n\n<p>Onder druk maakt Linux eerst de paginacache leeg voordat het overgaat op anonieme pagina\u2019s \u2013 zolang dat zinvol is. Als het werkgeheugen voor processen schaars wordt en er onvoldoende anonieme pagina\u2019s vrij zijn, begint het systeem te swappen. Een <strong>te laag<\/strong> Swappiness kan ertoe leiden dat belangrijk anoniem geheugen (heaps\/stacks) agressief wordt vastgehouden en dat in plaats daarvan nuttige cachepagina\u2019s worden verdrongen, wat de I\/O-belasting doet toenemen. Een <strong>te hoog<\/strong> Swappiness leidt daarentegen tot vroegtijdige uitbuiting en pieken in de latentie. Ik kies gematigde waarden, meet en observeer: het doel is dat mijn hotset in het RAM blijft en dat alleen koude, zelden gebruikte gegevens ten koste van de swap worden verplaatst \u2013 nooit de hete.<\/p>\n\n<h2>Beveiliging en duurzaamheid: gegevens op het medium<\/h2>\n\n<p>Write-back verbetert de prestaties, maar zorgt ervoor dat wijzigingen slechts kortstondig in het RAM-geheugen worden opgeslagen. Voor gegevens die onmiddellijk persistent moeten zijn, gebruik ik <code>fsync()<\/code> of <code>fdatasync()<\/code>. Daarnaast vertrouw ik op veilige standaardinstellingen zoals schrijfbeperkingen en journaling; risicovolle opties die deze beperkingen uitschakelen, vermijd ik. Op opslagniveau let ik op controller-caches: write-back-beleidsregels met batterij\/condensator zijn snel en veilig, maar onveilige caches zonder bescherming zijn riskant. Systeemwijd wordt afgedwongen <code>sync<\/code> Het wissen van alle gegevens \u2013 een grof hulpmiddel dat ik bewust en zelden gebruik. Zo combineer ik snelheid via de paginacache met schone persistentie op die punten waar dat bedrijfskritisch is.<\/p>\n\n<h2>WordPress en webstacks: handige tips<\/h2>\n\n<p>In de webstack stapelen de caches zich op: de Linux Page Cache versnelt statische assets, PHP-bestanden en configuraties, terwijl een PHP-OpCode-cache het uitvoeringspad en de bytecode in het geheugen bewaart. Ik zorg ervoor dat deployments het codepad niet voortdurend wijzigen en verminder het aantal bestandstoegangen door assets te bundelen. Een persistente objectcache-laag vermindert database-I\/O, waardoor de bestandssysteemcache de resterende veelgebruikte bestanden nog effectiever kan bedienen. Sessies en transi\u00ebnten sla ik, indien mogelijk, niet op de lokale schijf op, maar in geheugen- of netwerkcaches, zodat de paginacache zijn kracht kan uitspelen bij de overige, vaak gelezen bestanden. Resultaat: minder fysieke I\/O, snellere reacties en stabielere latenties.<\/p>\n\n<h2>Kort samengevat<\/h2>\n\n<p>De Linux-paginacache levert me snelle reacties op bestandsverzoeken <strong>RAM<\/strong> en vermindert het aantal dure toegangen tot de gegevensdrager aanzienlijk. Lees-hits versnellen applicaties, terwijl write-back veel afzonderlijke schrijfbewerkingen bundelt en de effici\u00ebntie verhoogt. Vrije opslagruimte blijft niet onbenut, maar fungeert als cache voor een responsief platform. Met meetpunten zoals <code>vrij -h<\/code>, <code>\/proc\/meminfo<\/code> en <code>iostat<\/code> merk ik het effect al voordat ik naar parameters zoals <code>vm.dirty_ratio<\/code> of <code>vm.vfs_cache_druk<\/code> ga. Wie bekend is met workloads, wijzigingen op een gecontroleerde manier test en de cache doelgericht inzet, bereikt een merkbaar betere <strong>Prestaties<\/strong> zonder wijzigingen in de code.<\/p>","protected":false},"excerpt":{"rendered":"<p>De Linux Page Cache gebruikt RAM als cache en verbetert zo de serverprestaties bij webhosting, WordPress en bestandstoegang.<\/p>","protected":false},"author":1,"featured_media":20533,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20540","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":"153","_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":null,"_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":"Linux Page","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":"20533","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/20540","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=20540"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/20540\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/20533"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=20540"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=20540"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=20540"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}