{"id":21026,"date":"2026-08-26T15:05:23","date_gmt":"2026-08-26T13:05:23","guid":{"rendered":"https:\/\/webhosting.de\/linux-transparent-page-cache-page-cache-unterschiede-optimierung-datencache\/"},"modified":"2026-08-26T15:05:23","modified_gmt":"2026-08-26T13:05:23","slug":"linux-transparante-paginacache-verschillen-tussen-paginacaches-optimalisatie-gegevenscache","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/linux-transparent-page-cache-page-cache-unterschiede-optimierung-datencache\/","title":{"rendered":"Linux Transparent Page Cache: basisprincipes en verschillen met de klassieke page cache"},"content":{"rendered":"<p>In twee zinnen leg ik uit hoe Linux de toegang tot bestanden in het RAM versnelt en hoe een <strong>transparante paginacache<\/strong> gebruikmaakt van grotere paginablokken om de administratieve rompslomp te verminderen. Daarnaast leg ik de verschillen uit met de klassieke paginacache met 4-KiB-pagina\u2019s, evenals het effect op de TLB, fragmentatie en het gedrag van de werklast.<\/p>\n\n<h2>Centrale punten<\/h2>\n\n<ul>\n  <li><strong>Paginagrootte<\/strong>: 4 KiB versus 2 MiB be\u00efnvloedt de granulariteit en effici\u00ebntie.<\/li>\n  <li><strong>TLB-afdruk<\/strong>: Grote sites schrappen vermeldingen, kleine blijven flexibel.<\/li>\n  <li><strong>Versnippering<\/strong>: Grote websites hebben aaneengesloten RAM nodig.<\/li>\n  <li><strong>Werklasten<\/strong>: Bij sequentieel gebruik is de winst groot, bij willekeurig gebruik iets minder.<\/li>\n  <li><strong>Controle<\/strong>: Testen, meten en vervolgens stap voor stap configureren.<\/li>\n<\/ul>\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-serverraum-8473.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Wat is de klassieke Linux-paginacache?<\/h2>\n\n<p>De klassieke paginacache bewaart veelgebruikte bestands pagina\u2019s in het werkgeheugen, zodat leesbewerkingen direct vanuit <strong>RAM<\/strong> plaatsvinden. Het werkt doorgaans met pagina\u2019s van 4 KiB en beheert elke pagina als een afzonderlijke eenheid in de cache. Hierdoor blijven veel kleine bestanden of veelgevraagde delen van grote bestanden beschikbaar, zonder de SSD of HDD te belasten. De kernel geeft voorrang aan actieve pagina\u2019s, verwijdert inactieve inhoud en reageert zo dynamisch op pieken in de belasting. Voor meer achtergrondinformatie verwijs ik naar een beknopte inleiding over de <a href=\"https:\/\/webhosting.de\/nl\/linux-paginacache-prestatieverbeteraar\/\">Prestaties van de paginacache<\/a>, waarin het basisprincipe op een praktijkgerichte manier wordt beschreven.<\/p>\n\n<h2>Waarom een transparante paginacache?<\/h2>\n\n<p>Veel afzonderlijke 4-KiB-pagina\u2019s zorgen voor extra administratief werk en verhogen de druk op de <strong>TLB<\/strong>. Grotere pagina's, zoals 2 MiB, kunnen dezelfde adresruimte met minder vermeldingen bestrijken en zo CPU-tijd besparen. Een transparante paginacache voegt bestands pagina's automatisch samen tot grotere eenheden, wanneer toegangs patronen en de opslaglocatie dit toelaten. Dit lijkt op het idee achter Transparent Huge Pages, maar heeft hier betrekking op een op bestanden gebaseerde cache in plaats van anoniem geheugen. Ik pas dergelijke functies pas toe nadat ik de toegangspatronen, fragmentatie en latentie-eisen heb begrepen, omdat grotere pagina\u2019s de granulariteit verhogen.<\/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\/LinuxPageCacheMeeting4321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Verschillen systematisch vergelijken<\/h2>\n\n<p>Om een duidelijk overzicht te geven, zet ik de belangrijkste kenmerken van de klassieke cache, de transparante paginacache en THP naast elkaar, zodat de keuze per <strong>Werkbelasting<\/strong> gaat gemakkelijker. De nadruk ligt op paginagrootte, TLB, fragmentatie, voordelen en risico\u2019s. De tabel toont sterke punten en beperkingen zonder marketingpraatjes. Ik lees de tabel van links naar rechts en kijk welke kolom het beste bij de belasting past. Vervolgens beslis ik of ik bij de 4-KiB-cache blijf of grotere pagina's ga testen.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Functie<\/th>\n      <th>Klassieke paginacache (4 KiB)<\/th>\n      <th>Transparante paginacache (bijv. 2 MiB)<\/th>\n      <th>THP (anonieme opslag)<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Paginagrootte\/granulariteit<\/td>\n      <td>Fijne, uiterst nauwkeurige caching<\/td>\n      <td>Grofweg, hele grote gebieden<\/td>\n      <td>Grof, grote hopen\/stapels<\/td>\n    <\/tr>\n    <tr>\n      <td>TLB-afdruk<\/td>\n      <td>Hoger door veel vermeldingen<\/td>\n      <td>Lager, minder vermeldingen<\/td>\n      <td>Lager, minder vermeldingen<\/td>\n    <\/tr>\n    <tr>\n      <td>Administratieve kosten<\/td>\n      <td>Hoog bij veel pagina\u2019s<\/td>\n      <td>Minder metagegevens<\/td>\n      <td>Minder metagegevens<\/td>\n    <\/tr>\n    <tr>\n      <td>Versnippering<\/td>\n      <td>Niet-kritisch, vereist geen contigu\u00efteit<\/td>\n      <td>Vereist aaneengesloten RAM<\/td>\n      <td>Vereist aaneengesloten RAM<\/td>\n    <\/tr>\n    <tr>\n      <td>Geschikte lasten<\/td>\n      <td>Kleine bestanden, willekeurige toegangen<\/td>\n      <td>Grote bestanden, sequenti\u00eble patronen<\/td>\n      <td>Grote heaps, databases in het RAM-geheugen<\/td>\n    <\/tr>\n    <tr>\n      <td>Risico's<\/td>\n      <td>Meer TLB- en CPU-overhead<\/td>\n      <td>Overfetch, pieken in de latentie bij split\/merge<\/td>\n      <td>Overfetch, pieken in de latentie bij split\/merge<\/td>\n    <\/tr>\n    <tr>\n      <td>Afhankelijkheid van kernel\/feature<\/td>\n      <td>Op grote schaal beschikbaar<\/td>\n      <td>Let op de versie\/implementatie<\/td>\n      <td>Distributie-instellingen controleren<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>De tabel is geen vervanging voor een test, maar geeft structuur aan mijn <strong>Besluit<\/strong>. Ik beoordeel eerst de toegangs patronen en de bestandsgrootte. Vervolgens meet ik de latentie, de CPU-tijd en de cache-hitrate, zowel met als zonder grote pagina\u2019s. Als benchmarks duidelijke voordelen laten zien zonder uitschieters, schaal ik voorzichtig op. Als er pieken optreden, rol ik terug of beperk ik het gebruik.<\/p>\n\n<h2>Hoe de kernel grote bestandspagina\u2019s vormt<\/h2>\n\n<p>Om grotere paginablokken in de paginacache te cre\u00ebren, heeft de kernel aaneengesloten bestandsgebieden in het geheugen nodig en voldoende coherente toegang. Een typisch voorbeeld is een \u2018promotion\u2019: meerdere pagina\u2019s van 4 KiB worden samengevoegd tot een groter folio. Omgekeerd vindt bij ongeschikte patronen een splitsing plaats, waarbij de eenheden weer worden opgesplitst in kleinere eenheden. Ik observeer deze overgangen vooral onder belasting, omdat promotie en splitsing kortstondig CPU-capaciteit kosten en LRU-lijsten actualiseren. Sequentiele lezers bevorderen promotie, terwijl sterk verspreide workloads eerder splitsingen veroorzaken.<\/p>\n\n<p>Readahead speelt hierbij een essenti\u00eble rol: wanneer er voldoende gegevens van tevoren worden ingelezen en deze gegevens vervolgens daadwerkelijk worden gebruikt, ontstaan er als het ware terloops grote folio\u2019s. Als applicaties daarentegen in kleine, onvoorspelbare stappen gegevens ophalen, blijft de cache gedetailleerd. Ook <strong>Writeback<\/strong> werkt samen met grote pagina\u2019s: als er veel aaneengesloten \u2018dirty pages\u2019 tegelijkertijd worden teruggeschreven, kan dit de doorvoersnelheid en het aantal IOPS ten goede komen, maar nemen de burst-groottes wel toe. Ik houd daarom rekening met de \u2018dirty tuning\u2019-parameters (bijv. <code>vm.vuile_achtergrond_bytes<\/code> en <code>vm.dirty_bytes<\/code>), om te grote flush-golven te voorkomen.<\/p>\n\n<h2>Bestandssystemen, I\/O-paden en hun invloed<\/h2>\n\n<p>Buffered I\/O profiteert rechtstreeks van de paginacache, Direct I\/O (<code>O_DIRECT<\/code>) heeft daar grotendeels geen invloed op. Voor databases of back-uptools die bewust gebruikmaken van Direct I\/O, heeft een transparante paginacache dus minder invloed. Bij <code>mmap()<\/code> hangt het effect af van het toegangs patroon: pagina voor pagina, voorwaarts lopende scans maken goed gebruik van grotere folio\u2019s; willekeurige sprongen niet. Met <code>posix_fadvise()<\/code> kan ik de kernel aanwijzingen geven (bijv. <code>SEQUENTIAL<\/code>, <code>WILLNEED<\/code>, <code>RANDOM<\/code>), die de readahead en de verdringing sturen. Dergelijke hints zijn geen garanties, maar ze vergroten de kans dat de cache bij mijn workload past.<\/p>\n\n<p>Bestandssystemen hebben hun eigen heuristieken. Op sommige systemen reageren ext4 en XFS heel redelijk op sequenti\u00eble stromen, terwijl Copy-on-Write-bestandssystemen met deduplicatie of compressie (bijvoorbeeld bomen met veel snapshots) andere uitvoerprofielen vertonen. Ik controleer daarom of de indeling en fragmentatie van het bestandssysteem grote aaneengesloten gebieden toelaten. Een defragmentatiebeurt voor sterk gefragmenteerde gegevens kan meetbare voordelen opleveren, maar moet altijd met de nodige voorzichtigheid en binnen onderhoudsvensters worden gepland.<\/p>\n\n<h2>Hardwarefactoren: architectuur, NUMA en apparaten<\/h2>\n\n<p>Niet elke architectuur gebruikt 4 KiB als basispagina. Op systemen met grotere basispagina\u2019s veranderen de granulariteit en het TLB-gedrag al standaard. Dit verschuift het nut van grote folio\u2019s in de cache. Daarnaast houd ik rekening met NUMA-topologie\u00ebn: Grote pagina\u2019s werken het beste als ze zich lokaal bevinden ten opzichte van de CPU die de I\/O-thread of de applicatie uitvoert. Daarom koppel ik workers aan knooppunten, houd ik per-NUMA-statistieken in de gaten en voorkom ik onnodige toegang op afstand. Onder Linux helpen mij per-knooppunt-metrieken (<code>\/sys\/devices\/system\/node\/node*\/meminfo<\/code>) en het vastzetten van de scheduler om de lokaliteit te behouden.<\/p>\n\n<p>Aan de apparaatzijde kijk ik naar de wachtrijen van de controller, de NVMe-diepte en de latentiecurve. Grote sites presteren goed met een hoge doorvoer en stabiele latentie, maar zijn gevoelig voor pieken in de tail-latentie. Een I\/O-scheduler die burst-belastingen afvlakt, kan hier het verschil maken. Readahead-waarden (<code>blockdev --getra\/--setra<\/code>) kalibreer ik zorgvuldig per apparaat en per workload.<\/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-differences-3942.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Meetmethodiek, KPI's en observeerbaarheid<\/h2>\n\n<p>Ik definieer vooraf een klein aantal, maar veelzeggende indicatoren: page-fault-ratio, cache-hitratio, CPU-tijd per verzoek, TLB-belasting, readahead-hits, latentiepercentielen (P50\/P95\/P99) en I\/O-mislukte toegangen. Voor het systeemoverzicht gebruik ik <code>vmstat<\/code>, <code>sar -B<\/code>, <code>iostat<\/code> en <code>pidstat<\/code>, om trends te herkennen. <code>\/proc\/meminfo<\/code> en <code>smaps<\/code> helpen bij het achterhalen wat er actief in het werkgeheugen staat; <code>plaattop<\/code> toont metadata-overhead. Indien nodig meet ik met <code>perf<\/code> TLB-misses en CPU-cycli onder re\u00eble belasting, om het effect van grote pagina\u2019s zichtbaar te maken.<\/p>\n\n<p>Een testrun bestaat voor mij uit drie fasen: opwarmen tot een stabiele hitrate, meetinterval onder gecontroleerde belasting, en afkoelen om eviction en writeback te observeren. Ik herhaal runs met dezelfde dataset en wisselende parameters (bijv. readahead, THP-modus <code>altijd\/slecht advies\/nooit<\/code>), om betrouwbare conclusies te kunnen trekken. Uitschieters laat ik niet buiten beschouwing: als P99 slechter wordt, terwijl het gemiddelde daalt, past de opzet meestal niet binnen mijn streefbandbreedte.<\/p>\n\n<h2>Typische voorbeelden uit de praktijk<\/h2>\n\n<p>Streaming- en media-workloads lezen grote bestanden grotendeels voorwaarts. Hier scoren grote folio\u2019s regelmatig goed, omdat de druk op de TLB en de administratieve lasten afnemen. Back-up\/herstel en replicatie met lange, sequenti\u00eble blokken bieden vergelijkbare voordelen, vooral wanneer meerdere processen dezelfde gebieden lezen. Machine learning-pijplijnen profiteren ervan wanneer datasets worden gebundeld en in de cache worden bewaard; sterk willekeurige steekproeven uit veel kleine bestanden dempen dit effect echter, tenzij men vooraf overschakelt op containerformaten met aaneengesloten blokken.<\/p>\n\n<p>Build- en CI-omgevingen met duizenden kleine bestanden werken meestal beter met een granulariteit van 4 KiB. Daar is snelle, nauwkeurige beschikbaarheid van veelgebruikte fragmenten van belang. Ik investeer hier in een hoog RAM-aandeel voor Active(file), zinvolle readahead per apparaat en eventueel in applicatiespecifieke caches (bijv. dependency-caches), in plaats van grote pagina\u2019s in de kernel af te dwingen.<\/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_tech_4829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Bronnenbeheer: Cgroups en working set-bescherming<\/h2>\n\n<p>In multi-tenant-omgevingen beperk en bescherm ik het geheugen per service. Met cgroup v2 kunnen processen die veel paginacache gebruiken nauwkeurig worden afgerekend en indien nodig via <code>geheugen.laag<\/code> beschermen, zodat belangrijke werkgeheugensets minder vaak worden verdrongen. <code>geheugen.hoog<\/code> stelt zachte bovengrenzen vast, <code>geheugen.max<\/code> strikte limieten. Ik observeer hoe \u2018fairness\u2019 en \u2018eviction\u2019 werken wanneer meerdere services dezelfde hostcache delen. Grote pagina\u2019s kunnen hier helpen om de CPU te ontlasten, maar kunnen ook leiden tot grotere verdringingsblokken. Daarom stel ik de beschermingslimieten in kleine stapjes af en controleer ik de LRU-dynamiek.<\/p>\n\n<h2>Foutpatronen en tegenmaatregelen<\/h2>\n\n<p>Als promotie en split vaak samen voorkomen, zie ik schommelingen in de latentie, een hoog kernel-CPU-gebruik en een wisselende hitrate. Oplossing: readahead aanpassen, split-cascades vermijden, workloads ontkoppelen of de agressiviteit van grote pagina\u2019s verminderen. Bij overfetch-symptomen (veel in de cache, toenemende swapdruk, dalende hitrate voor kleine hotsets) schakel ik over naar een fijnere granulariteit of isoleer ik grote lezers op speciale knooppunten. Als writeback-bursts de tail-latentie verhogen, stel ik strengere limieten voor dirty bytes in en maak ik de flush-intervallen gelijkmatiger.<\/p>\n\n<p>NUMA-jitter los ik op door middel van CPU\/geheugen-pinning en een zorgvuldige plaatsing van de I\/O-threads. Als er TLB-misses optreden, maar de applicatie onverminderd traag blijft, controleer ik op lock-contention, bestandssysteemvergrendelingen en het effect van compressie\/decryptie in de stack. Een prestatiewinst door grote pagina's is pas echt een succes als deze zich aan het eindpunt van de applicatie manifesteert.<\/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_pagecache_schreibtisch4823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praktisch tijdschema voor toetsen<\/h2>\n\n<p>Ik begin met een baseline: de huidige kernel, THP-status (<code>\/sys\/kernel\/mm\/transparent_hugepage\/<\/code>), readahead-waarden, I\/O-scheduler, bestands- en schijfinrichting. Vervolgens stel ik twee tot drie concrete hypothesen op (bijv. \u201esequenti\u00eble mediastreams: -10% CPU, stabielere P99\u201c). Vervolgens stel ik vaste datasets en belastingprofielen vast die realistische verkeerspatronen weergeven. Elke testreeks krijgt identieke opwarmtijden, identieke duur en identieke metrische registratie.<\/p>\n\n<p>Ik varieer telkens slechts \u00e9\u00e9n parameter: eerst readahead, dan de agressiviteit bij grote pagina\u2019s, en ten slotte de LRU\/Dirty-instellingen. Na elke stap sla ik de statistieken en aantekeningen op, zodat latere kernel-updates vergelijkbaar blijven. Pas wanneer twee onafhankelijke runs dezelfde trend laten zien en de P95\/P99-latenties stabiel zijn, breng ik de wijziging door naar een beperkte productiegroep. Een rollback-plan met duidelijke drempelwaarden (bijv. \u201eP99 &gt; +15% gedurende 5 min\u201c) hoort daar altijd bij.<\/p>\n\n<h2>Toegangspatronen en gevoeligheid<\/h2>\n\n<p>Sequenti\u00eble lezers die met grote bestanden werken, hebben vaker baat bij grotere <strong>Pagina's<\/strong>. Willekeurige toegangen tot veel kleine bestanden verlopen meestal beter met 4 KiB, omdat de cache dan alleen de benodigde fragmenten in voorraad houdt. Gemengde werkbelastingen vereisen metingen met realistische datasets, aangezien synthetische tests vaak te optimistisch uitvallen. Ik let erop of overfetch geheugen in beslag neemt dat elders ontbreekt. Een kleine winst in CPU-tijd is niet de moeite waard als daardoor de LRU-druk toeneemt en de latenties omhoogschieten.<\/p>\n\n<h2>Webhostingscenario's met veel kleine bestanden<\/h2>\n\n<p>Bij typische shared hosting worden talloze kleine scripts, afbeeldingen en bestanden verwerkt, die de cache van 4 KiB prima aankan <strong>Handgreep<\/strong> heeft. Grote paginas bieden hier zelden een meerwaarde, aangezien bestanden vaak kleiner zijn dan 2 MiB of onregelmatig worden gebruikt. In plaats daarvan investeer ik in voldoende RAM, zinvolle readahead per apparaat en caches op applicatieniveau, zoals OPCache. Daarnaast controleer ik of statische assets via een HTTP-cache sneller worden geleverd dan vanaf het blokapparaat. Pas wanneer belastingsprofielen grotere bestanden laten zien, sta ik grotere paginacache-pagina\u2019s toe.<\/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-differences-3942.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Databases, caches en logbestanden<\/h2>\n\n<p>In-memory-databases en grote heaps profiteren vaak van THP in de anonieme modus <strong>Geheugen<\/strong>. Bij bestandsgebaseerde engines en log-pijplijnen met lange, sequenti\u00eble leesbewerkingen kan een transparante paginacache eveneens voordelen opleveren. Ik test op reproduceerbare wijze of het aantal paginastoringen afneemt en de CPU rustiger draait. Tegelijkertijd kijk ik of overfetch het gebruikte RAM-geheugen doet stijgen en of de opstarttijden veranderen. Een korte toelichting helpt bij de start: ik gebruik deze handleiding om <a href=\"https:\/\/webhosting.de\/nl\/transparante-huge-pages-prestatieverbeteraar-of-probleem-bij-linux-optimalisatie\/\">THP beoordelen<\/a> en de wisselwerkingen correct in te schatten.<\/p>\n\n<h2>Virtualisatie en containers<\/h2>\n\n<p>Meerdere VM's of containers delen de host-kernel en daarmee de <strong>Pagina<\/strong>-Cache. Veelgebruikte binaire bestanden en bibliotheken worden dan vanuit dezelfde cache aan alle instanties geleverd, wat I\/O bespaart. THP in de guest kan de CPU-belasting verminderen, maar vereist wel dat er rekening wordt gehouden met NUMA-zones en overcommit. Ik meet per NUMA-node, zodat grote pagina's niet door het hele systeem hoeven te reizen. Als er onder belasting jitter optreedt, verlaag ik de agressiviteit (madvise) of schakel ik THP selectief uit, totdat de curven weer vloeiend zijn.<\/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_tech_4829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configuratie controleren en op de juiste manier instellen<\/h2>\n\n<p>Ik begin met een nuchtere <strong>Inventaris<\/strong>: Welke kernelversie, welke standaardinstellingen, welke mount-opties, welke readahead-waarden? De status van THP controleer ik onder \/sys\/kernel\/mm\/transparent_hugepage\/ (bijv. enabled, defrag, khugepaged). Voor het gedrag van de paginacache kijk ik naar \/proc\/meminfo, per-node-statistieken en readahead per blok. Ik voer wijzigingen nooit blindelings door, maar test ze eerst op een staging-omgeving met echte gegevens. Pas daarna neem ik stabiele configuraties over naar de productieomgeving.<\/p>\n\n<h2>Fijnafstemming: readahead, eviction en monitoring<\/h2>\n\n<p>Grote pagina\u2019s werken alleen als readahead, de I\/O-scheduler en LRU goed functioneren <strong>samen<\/strong>spelen. Ik houd de page-fault-rate, misses, CPU-tijd en eventuele latentiepieken bij het splitsen en samenvoegen van grote pagina\u2019s in de gaten. Onder druk ben ik benieuwd hoe snel de cache oude pagina\u2019s verdringt en of er belangrijke bestanden uitvallen. Een goed startpunt om naar verdringing te kijken, is dit artikel over <a href=\"https:\/\/webhosting.de\/nl\/server-pagina-cache-eviction-linux-geheugen-print-optimalisatie-inzicht\/\">Uitzetting onder druk van het geheugen<\/a>, waarin de typische patronen worden toegelicht. Daarna pas ik \u2018readahead\u2019, de opties voor het bestandssysteem en, indien nodig, het gebruik van grote pagina\u2019s voorzichtig aan.<\/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_pagecache_schreibtisch4823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Checklist voor de praktijk zonder mythes<\/h2>\n\n<p>Ik begin met duidelijke doelstellingen: minder CPU-tijd, een stabielere latentie, passende <strong>Raakpercentage<\/strong> in de paginacache. Vervolgens definieer ik meetpunten en kies ik re\u00eble workloads die pieken en gemengde belastingen vertonen. Daarna test ik stapsgewijs grotere pagina\u2019s, eerst op de staging-omgeving en daarna op beperkte schaal in productie. Ik zorg dat ik rollback-plannen achter de hand heb voor het geval er overfetch, fragmentatie of jitter optreedt. Tot slot documenteer ik de effecten, zodat de opstelling reproduceerbaar blijft en latere kernel-updates kunnen worden ge\u00ebvalueerd.<\/p>\n\n<h2>Kort samengevat<\/h2>\n\n<p>De klassieke cache van 4 KiB blijft voor veel toepassingen de betrouwbare <strong>Basis<\/strong>, omdat het gedetailleerd en zuinig omgaat met RAM. Een transparante paginacache vermindert de druk op de TLB en de hoeveelheid metadata wanneer grote bestanden sequentieel worden gelezen. THP richt zich op anonieme geheugengebieden en kan grote heaps ondersteunen, maar vereist zorgvuldigheid vanwege mogelijke latentiepieken. Ik neem de beslissing op basis van gegevens: meten, vergelijken en vervolgens implementeren. Wie zo te werk gaat, bereikt voorspelbare responstijden, een zinvol RAM-gebruik en een merkbaar rustigere CPU.<\/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-setup-5726.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>","protected":false},"excerpt":{"rendered":"<p>Ontdek hoe de Linux Transparent Page Cache werkt, wat de verschillen zijn met de klassieke page cache en hoe je je geheugenbeheer kunt optimaliseren voor maximale prestaties. Focus: Transparent Page Cache.<\/p>","protected":false},"author":1,"featured_media":21019,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21026","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":"121","_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":"transparent page cache","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":"21019","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21026","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=21026"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21026\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/21019"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=21026"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=21026"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=21026"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}