{"id":16421,"date":"2025-12-31T18:20:15","date_gmt":"2025-12-31T17:20:15","guid":{"rendered":"https:\/\/webhosting.de\/filesystem-caching-linux-page-cache-cacheboost\/"},"modified":"2025-12-31T18:20:15","modified_gmt":"2025-12-31T17:20:15","slug":"bestandssysteem-caching-linux-paginacache-cacheboost","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/filesystem-caching-linux-page-cache-cacheboost\/","title":{"rendered":"Bestandssysteemcaching in Linux-hosting: pagina-cache goed begrijpen"},"content":{"rendered":"<p>De Linux Page Cache bepaalt hoe snel hostingworkloads bestanden lezen en schrijven, omdat deze vaak gebruikte gegevens in het RAM-geheugen bewaart en zo dure apparaattoegang voorkomt. Ik laat zien hoe <strong>Bestandssysteem<\/strong> Caching in Linux-hosting werkt, welke statistieken tellen en hoe ik de cache geschikt maak voor dagelijks gebruik zonder de <strong>Server<\/strong>-belasting te verhogen.<\/p>\n\n<h2>Centrale punten<\/h2>\n<ul>\n  <li><strong>Pagina cache<\/strong> houdt bestandsblokken in het RAM-geheugen en vermindert latentie.<\/li>\n  <li><strong>Vuile pagina's<\/strong> verzamelen schrijftoegangen en schrijven gebundeld terug.<\/li>\n  <li><strong>LRU<\/strong>-Strategie\u00ebn verwijderen oude vermeldingen voor nieuwe gegevens.<\/li>\n  <li><strong>Controle<\/strong> met free, \/proc\/meminfo, vmstat, iostat zorgt voor duidelijkheid.<\/li>\n  <li><strong>Optimalisatie<\/strong> door RAM, Logrotate, Opcache en zinvolle limieten.<\/li>\n<\/ul>\n\n<h2>Wat is de Linux-paginacache?<\/h2>\n<p>De Linux Page Cache slaat vaak gelezen bestandsblokken op in het werkgeheugen en versnelt zo elke nieuwe toegang tot <strong>Bestanden<\/strong>. Ik profiteer er direct van, omdat RAM-toegang in microseconden plaatsvindt, terwijl zelfs snelle SSD's milliseconden nodig hebben en daarmee aanzienlijk langzamer zijn dan <strong>Geheugen<\/strong> in het RAM-geheugen. Wanneer een toepassing een bestand opent, slaat de kernel de gelezen blokken op in de cache en verwerkt toekomstige verzoeken rechtstreeks vanuit het werkgeheugen. Dit werkt transparant voor programma's, ik hoef niets aan te passen of opnieuw te configureren. Hosting-workloads zoals webservers, PHP-FPM, beeldlevering of logboekleesprocessen raken voortdurend de cache en besparen I\/O.<\/p>\n\n<h2>Zo werkt de cache bij het lezen<\/h2>\n<p>Bij het voor het eerst lezen van een bestand laadt het systeem blokken in de cache en markeert deze als hot, zodat ze bij herhaalde toegang beschikbaar blijven en de <strong>Tijd<\/strong> voor de tweede vereiste extreem kort is. Als ik een bestand van 100 MB twee keer achter elkaar lees, komt de tweede keer vrijwel volledig uit het RAM-geheugen. De kernel gebruikt hiervoor strategie\u00ebn zoals LRU (Least Recently Used) en geeft voorrang aan recent gebruikte items, zodat actuele webcontent langer in de cache blijft en koude data verdwijnt. Deze logica sluit goed aan bij hostingpatronen, omdat veel bezoekers herhaaldelijk identieke afbeeldingen, CSS- en JavaScript-bestanden openen, die ik dankzij <strong>Cache<\/strong> snel lever. Het trefpercentage stijgt met de cachegrootte, dus met het beschikbare RAM-geheugen.<\/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\/2025\/12\/linux-pagecache-server-7192.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Schrijven en dirty pages begrijpelijk<\/h2>\n<p>Bij het schrijven komen gegevens eerst als dirty pages in de cache terecht, dat wil zeggen als gewijzigde blokken die de kernel nog niet naar de gegevensdrager heeft teruggeschreven en die ik via <strong>Writeback<\/strong>-mechanismen tijdig synchroniseren. Ik kan het gedrag gemakkelijk live observeren: als ik met dd een bestand van 10 MB aanmaak, stijgen de dirty-waarden totdat de kernel ze in \u00e9\u00e9n keer naar de SSD schrijft. Een handmatige sync dwingt het systeem om de cache consistent te maken en zet de dirty-metriek weer op nul. Dit bundelen spaart I\/O, omdat het veel kleine bewerkingen samenvoegt tot grotere overdrachten en zo de <strong>Prestaties<\/strong> per schrijfbewerking verbeterd. De moderne per-apparaat writeback-benadering houdt parallelle schijven onafhankelijk bezig en verkort wachttijden.<\/p>\n\n<h2>Cache-architectuur: Dentry\/Inode vs. paginacache<\/h2>\n<p>Om het plaatje compleet te maken, moet worden vermeld dat Linux niet alleen bestandsgegevens in de cache opslaat. Naast de eigenlijke <strong>Pagina cache<\/strong> Voor inhoud bestaan er Dentry- en Inode-caches, die directorystructuren, bestandsnamen en metadata in het RAM-geheugen bewaren. Ze besparen dure padresoluties en Inode-lookups. In <em>gratis -m<\/em> verschijnen deze aandelen in waarde <strong>cached<\/strong> ook op, terwijl <strong>buffers<\/strong> Ik bedoel eerder buffers die verband houden met blokapparaten. In \/proc\/meminfo zie ik een meer gedetailleerde uitsplitsing (bijv. dentries, inactive(file), active(file)). Voor hostingworkloads met veel kleine bestanden zijn deze metagegevenscaches essentieel, omdat ze het aantal daadwerkelijke apparaattoegangen per HTTP-verzoek extra verminderen.<\/p>\n\n<h2>Kerncijfers correct interpreteren<\/h2>\n<p>Ik controleer eerst free -m en let op de kolommen voor cached en de Mem- en Swap-regels om het effect van de cache goed te kunnen beoordelen en de werkelijke <strong>Gebruik<\/strong> begrijpen. Uit \/proc\/meminfo lees ik waarden zoals Cached, Dirty, Writeback en Buffers, die samen een goed beeld geven van de geheugentoestand. vmstat 1 geeft continu weer of het systeem wacht vanwege I\/O, en iostat vult details per apparaat aan. Cruciaal: Linux gebruikt vrij RAM als cache, maar markeert het tijdelijk als bezet, hoewel applicaties het indien nodig onmiddellijk kunnen terugvragen. Ik beoordeel dus altijd de totale situatie, inclusief <strong>Werkbelasting<\/strong> en niet slechts \u00e9\u00e9n enkel cijfer.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Metriek<\/th>\n      <th>Bron\/commando<\/th>\n      <th>Dat betekent<\/th>\n      <th>Typisch signaal<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>In cache opgeslagen<\/td>\n      <td>free -m, \/proc\/meminfo<\/td>\n      <td>RAM-aandeel voor bestandsgegevens<\/td>\n      <td>Hoge waarde bij frequente bestandstoegang<\/td>\n    <\/tr>\n    <tr>\n      <td>Vies<\/td>\n      <td>\/proc\/meminfo<\/td>\n      <td>Nog niet teruggeschreven pagina's<\/td>\n      <td>Stijgt bij intensieve schrijfbewerkingen, daalt na synchronisatie<\/td>\n    <\/tr>\n    <tr>\n      <td>Writeback<\/td>\n      <td>\/proc\/meminfo<\/td>\n      <td>Actieve terugschrijfbewerkingen<\/td>\n      <td>Waarden ongelijk aan nul tijdens flush-fase<\/td>\n    <\/tr>\n    <tr>\n      <td>bi\/bo (vmstat)<\/td>\n      <td>vmstat 1<\/td>\n      <td>Blok-I\/O in\/uit<\/td>\n      <td>Pieken geven cache-missers of flushes aan<\/td>\n    <\/tr>\n    <tr>\n      <td>r\/s, w\/s (iostat)<\/td>\n      <td>iostat -xz 1<\/td>\n      <td>Lees-\/schrijfbewerkingen per seconde<\/td>\n      <td>Sprongen bij Misses, constante achtergrondruis ok<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/linuxcachemeeting2347.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Voordelen in het dagelijkse hostingwerk<\/h2>\n<p>Een goed gevulde paginacache vermindert de I\/O-wachttijden aanzienlijk en verplaatst de gegevenstoegang van de gegevensdrager naar het RAM-geheugen, wat de latentie van afzonderlijke verzoeken sterk vermindert en de <strong>Reactietijd<\/strong> van websites merkbaar vermindert. Veelgebruikte afbeeldingen, CSS- en HTML-bestanden blijven in de cache, zodat de webserver ze zonder omweg via de SSD kan bedienen. Bij veel verkeer telt het aantal hits: hoe meer herhalingen, hoe groter het voordeel. In scenario's met een hoge mate van parallelliteit ontlast de cache het geheugenniveau en vlakt piekbelastingen af. Voor een beter begrip van de verbanden tussen geheugen-, web- en proxycaches is het de moeite waard om eens te kijken naar <a href=\"https:\/\/webhosting.de\/nl\/caching-hierarchieen-webtechnologie-hosting-boost\/\">Caching-hi\u00ebrarchie\u00ebn<\/a>, zodat ik elk niveau zinvol kan gebruiken en <strong>Bronnen<\/strong> verspil niet.<\/p>\n\n<h2>De cachegrootte slim be\u00efnvloeden<\/h2>\n<p>Ik be\u00efnvloed het cache-effect op twee manieren: meer RAM en minder onnodige bestandstoegangen, zodat er ruimte vrij blijft voor veelgebruikte gegevens en de kernel de juiste blokken in de cache kan plaatsen. <strong>Cache<\/strong> houdt. Logrotate met Gzip ruimt grote logbestanden op, vermindert de hoeveelheid bestanden in het werkgeheugen en voorkomt dat logs belangrijke webassets verdringen. Grote eenmalige overdrachten zoals back-ups of SQL-dumps markeer ik indien mogelijk als minder relevant door ze buiten de piekuren te verwerken. Het handmatig leegmaken van de kernelcache met echo 3 &gt; \/proc\/sys\/vm\/drop_caches gebruik ik alleen in tests, omdat dit de productieve cachemix vernietigt en de <strong>Latency<\/strong> kortstondig verhoogd. Uiteindelijk is de hoeveelheid werk doorslaggevend: hoe beter deze in het RAM-geheugen past, hoe constanter de prestaties blijven.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/linux-page-cache-erklaert-7273.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Directe I\/O, fsync en consistentie<\/h2>\n<p>Niet elke toegang verloopt via de paginacache. Sommige workloads openen bestanden met O_DIRECT of O_SYNC en omzeilen daarmee bewust de caching of dwingen onmiddellijke persistentie af. Dat is handig als dubbele buffering (databasebufferpool plus paginacache) moet worden vermeden of als consistentie belangrijker is dan latentie. Voor web- en media-workloads blijf ik meestal bij normale, gebufferde I\/O, omdat het trefpercentage meestal hoger is. Het is ook belangrijk om fsync te begrijpen: applicaties die vaak fsync uitvoeren op logbestanden, stimuleren writeback-cycli en kunnen I\/O-pieken veroorzaken. Ik bundel dergelijke oproepen waar mogelijk of stel zinvolle applicatie-flush-intervallen in om de <strong>Doorvoer<\/strong> hooghouden.<\/p>\n\n<h2>Mount-opties: relatime, noatime en Co.<\/h2>\n<p>Elke bestandstoegang kan de atime (access time) bijwerken en zo extra schrijfbewerkingen activeren. Met <strong>relatime<\/strong> (tegenwoordig standaard) worden atimes alleen indien nodig aangepast, wat I\/O aanzienlijk vermindert. In pure webworkloads, waarin geen op atime gebaseerde logica wordt gebruikt, stel ik vaak <strong>noatime<\/strong>, om nog minder schrijfbewerkingen te veroorzaken. Ook relevant in de praktijk: geschikte blokgroottes, barri\u00e8re-standaardinstellingen en indien nodig compressie op bestandssysteemniveau, als het patroon en de CPU-ruimte dit toelaten. Deze mount-opties dragen direct bij aan een hogere cache-hitratio, omdat er minder onnodige metagegevensupdates zijn die de <strong>Geheugen<\/strong>-Paden belasten.<\/p>\n\n<h2>Containers en cgroups: paginacache in multi-tenant-gebruik<\/h2>\n<p>Bij containerhosting delen meerdere workloads de globale paginacache. Geheugenlimieten via cgroups bepalen hoeveel anoniem geheugen (heap\/stack) per container is toegestaan, maar de bestandscache wordt beheerd door de hostkernel. Als een container warm loopt en veel nieuwe bestanden leest, verdringt deze mogelijk cachepagina's van andere containers. Ik gebruik daarom geheugen- en I\/O-controles (memory.high, memory.max, io.max) om piekbelastingen af te vlakken en de eerlijkheid te vergroten. OverlayFS, dat vaak in containers wordt gebruikt, voegt extra metadatlagen toe. Dit kan van invloed zijn op padresoluties en copy-on-write-schrijfpaden. Ik meet specifiek of overlay-lagen de latentie merkbaar verhogen en overweeg voor statische assets bind-mounts zonder extra lagen.<\/p>\n\n<h2>Voorverwarmen en beschermen van de cache<\/h2>\n<p>Na een herstart of na grote implementaties is de cache leeg. Ik kan hotsets gericht <strong>voorverwarmen<\/strong>, door veelgevraagde assets \u00e9\u00e9n keer sequentieel te lezen. Dit vermindert de cold start-latentie in de eerste minuten aanzienlijk. Omgekeerd vermijd ik cachevervuiling: tools voor back-ups, malwarescans of grote sequenti\u00eble kopieerbewerkingen lees ik met een lage prioriteit (nice\/ionice) en markeer ik indien mogelijk met Fadvise als minder belangrijk (DONTNEED), zodat de pagina's na de doorloop weer verdwijnen. Zo blijft de cache voor webverkeer gericht op de echt populaire pagina's. <strong>Gegevens<\/strong>.<\/p>\n\n<h2>NUMA en grote hosts<\/h2>\n<p>Op NUMA-systemen speelt geheugenlokaliteit een rol. De paginacache bevindt zich fysiek in knooppunten en externe toegang verhoogt de latentie. Ik let op een consistente CPU- en geheugenbinding voor services met intensieve bestandstoegang en controleer of zone_reclaim_mode zinvol is. In de praktijk helpt het vaak om centrale web- en PHP-processen per NUMA-knooppunt te bundelen, zodat het meest gebruikte deel van de cache lokaal blijft. Tegelijkertijd houd ik in de gaten of grote Java- of databaseprocessen door hun eigen geheugenbehoefte de paginacache verdringen \u2013 in dat geval schaal ik het RAM-geheugen op of scheid ik workloads.<\/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\/2025\/12\/linux_cache_office_4832.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NFS en gedeeld geheugen<\/h2>\n<p>In clusteropstellingen met NFS of vergelijkbare netwerkbestandssystemen is caching lastiger. De paginacache werkt lokaal op de consumerende host, terwijl wijzigingen op een ander knooppunt via protocollen ongeldig moeten worden gemaakt. Ik kalibreer daarom attribuutcaches en ongeldigverklaringintervallen zodanig dat de consistentie behouden blijft zonder al te veel I\/O te genereren. Voor statische webassets op gedeelde opslag is het de moeite waard om hervalidaties te beperken en implementaties atomair te maken (bijv. directory-uitwisseling), zodat de cache niet onnodig wordt leeggemaakt. Waar mogelijk repliceer ik hotsets naar de afzonderlijke webknooppunten om maximale <strong>Slagingspercentages<\/strong> te bereiken.<\/p>\n\n<h2>Tmpfs en tijdelijke gegevens<\/h2>\n<p>Voor tijdelijke, vaak gelezen gegevens zoals sessiebestanden, build-artefacten of korte uploadwachtrijen gebruik ik <strong>tmpfs<\/strong> . Hierdoor bespaar ik volledig op apparaattoegang en laat ik de paginacache in feite het primaire opslagniveau worden. Ik dimensionneer tmpfs echter voorzichtig: het gebruikt RAM (en eventueel swap), en te grote tmpfs-mounts kunnen ruimte innemen van andere caches. Een geregeld opruimproces (bijv. systemd-tmpfiles) voorkomt dat gegevens zich ophopen en het werkgeheugen tekort komen.<\/p>\n\n<h2>Werkbelastingspatronen: klein versus groot, sequentieel versus willekeurig<\/h2>\n<p>Het ideale cachegedrag hangt sterk af van het patroon. Veel kleine, vaak terugkerende bestanden profiteren maximaal van LRU en van een hoog percentage. <strong>Actief (bestand)<\/strong>. Grote bestanden die slechts eenmaal worden gelezen (back-ups, mediatranscoderingen) mogen daarentegen niet de cache domineren. Ik stel read_ahead_kb gematigd in, zodat sequenti\u00eble lezers sneller worden zonder willekeurige toegangen op te blazen. Op webservers met veel statische bestanden activeer ik zero-copy-paden (sendfile, splice) om kopie\u00ebn in de gebruikersruimte te vermijden \u2013 de paginacache levert dan rechtstreeks in de socket, wat CPU bespaart en de latentie afvlakt.<\/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\/2025\/12\/linux_pagecache_schreibtisch4872.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Uitgebreide observatie en symptomen<\/h2>\n<p>Naast vmstat en iostat bekijk ik indien nodig ook de reclaim-statistieken (bijv. Active\/Inactive, pgscan\/pgsteal via \/proc\/meminfo) om te zien of het systeem agressief pagina voor pagina terugwint. Frequente major page faults, stijgende IO-wait-waarden en aanhoudend hoge writeback-tijden duiden erop dat de cache onder druk staat. In dergelijke fasen controleer ik eerst of ik de werklast kan verminderen of het RAM-geheugen kan vergroten. Als het aantal missers hoog blijft, segmenteer ik de gegevens (bijv. scheiding van zeldzame archieven en veelgebruikte webassets), zodat het LRU-mechanisme de juiste blokken voorrang geeft.<\/p>\n\n<h2>Praktische vuistregels<\/h2>\n<ul>\n  <li>Ik plan de <strong>RAM<\/strong> zodat hotsets (statische webassets + actieve delen van databases) 1-2 keer erin passen. Dit verdubbelt de kans op cache-hits tijdens pieken in het verkeer.<\/li>\n  <li>Ik vermijd swapping consequent: zodra anonieme pagina's worden uitbesteed, concurreert de pager met de paginacache om I\/O \u2013 latenties raken in de war. Ik houd swappiness gematigd.<\/li>\n  <li>Ik roteer logbestanden korter, comprimeer oudere generaties en zorg ervoor dat chatty-logs niet met webassets strijden om ruimte in de cache.<\/li>\n  <li>Ik groepeer implementaties die veel bestanden wijzigen in een klein aantal atomaire stappen. Zo maak ik minder cache-items tegelijk ongeldig en houd ik de <strong>Raakpercentage<\/strong> hoog.<\/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\/2025\/12\/linux-pagecache-server-7192.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Bestandssystemen en cache-toegang<\/h2>\n<p>Het bestandssysteem be\u00efnvloedt hoe effici\u00ebnt de kernel gegevens opslaat en terugschrijft. Daarom ben ik bekend met de eigenschappen van Ext4, XFS en ZFS en pas ik de keuze aan mijn workloads aan, zodat de <strong>Cache<\/strong> optimaal werkt. Ext4 levert solide allround prestaties, XFS blinkt uit bij parallelle schrijfbelastingen, ZFS heeft eigen caching-niveaus zoals ARC. Afhankelijk van het patroon \u2013 veel kleine bestanden versus grote media-objecten \u2013 gedragen de metagegevens en schrijfpaden zich verschillend. Ik meet re\u00eble workloads voordat ik het platform vastleg. Voor een compact overzicht gebruik ik het artikel <a href=\"https:\/\/webhosting.de\/nl\/ext4-xfs-zfs-hosting-prestaties-vergelijking-opslag\/\">Ext4, XFS en ZFS in vergelijking<\/a> en stem instellingen zoals mount-opties af, zodat de kernel geen onnodige <strong>Misses<\/strong> geproduceerd.<\/p>\n\n<h2>Databases, Opcache en paginacache<\/h2>\n<p>Bij MySQL en MariaDB neemt de InnoDB-bufferpool het grootste deel van de gegevenspagina's en indexen voor zijn rekening, terwijl de paginacache bovendien bestandssysteemblokken versnelt en zo de totale I\/O verlaagt, wat de <strong>Query<\/strong>-Latencies verminderd. Ik stel de bufferpool zo groot in dat hotsets erin passen, anders produceert de engine onnodige schijftoegang. Voor PHP-toepassingen combineer ik Opcache voor bytecode en APCu voor toepassingsgerelateerde gegevens, waardoor ik de druk op de paginacache verminder. Statische assets blijven kandidaten voor de bestandssysteemcache en laden razendsnel. Deze gelaagdheid voorkomt dubbel werk en houdt de <strong>CPU<\/strong> vrij voor dynamische delen.<\/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\/2025\/12\/linux_cache_office_4832.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoring en diagnose<\/h2>\n<p>Ik bekijk vmstat 1 voor geheugen- en I\/O-signalen in realtime, controleer iostat -xz 1 per apparaat en kijk in \/proc\/meminfo naar Dirty, Cached, Writeback, zodat ik oorzaken snel kan beperken en gericht kan aanpakken. <strong>act<\/strong> kan. Een permanent hoge IO-Wait-waarde duidt op knelpunten, die ik eerst met caching en RAM oplos. Vervolgens controleer ik of het bestandssysteem, RAID of SSD-firmware vertraging veroorzaken. Als IO-Wait kritisch blijft, analyseer ik de toegangsfrequentie van applicaties en caching-hitpercentages. Voor een eerste kennismaking met diagnosepaden helpt mij <a href=\"https:\/\/webhosting.de\/nl\/io-wait-begrijpen-geheugenbottleneck-oplossen-optimalisatie\/\">IO-Wait begrijpen<\/a>, om symptomen van oorzaken te scheiden en doelgerichte <strong>Stappen<\/strong> af te leiden.<\/p>\n\n<h2>Tuningparameters zonder risico<\/h2>\n<p>Ik pas slechts enkele kernelparameters aan en test wijzigingen op een gecontroleerde manier, omdat er goede standaardinstellingen bestaan en kleine correcties vaak voldoende zijn om <strong>Effici\u00ebntie<\/strong> te winnen. vm.dirty_background_bytes bepaalt vanaf welke drempel het systeem asynchroon begint te schrijven, terwijl vm.dirty_bytes de bovengrens voor dirty pages vastlegt. Wie deze waarden in bytes in plaats van in procenten instelt, krijgt een stabiele basis, onafhankelijk van de RAM-uitbreiding. Bovendien be\u00efnvloedt read_ahead_kb het vooraf laden van gegevens per blokapparaat, wat sequentieel lezen versnelt, maar neutraal blijft bij willekeurige toegangen. Ik documenteer alle stappen en keer bij bijwerkingen snel terug naar de oorspronkelijke <strong>Waarden<\/strong> terug.<\/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\/2025\/12\/linux_pagecache_schreibtisch4872.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Moderne functies in het kort uitgelegd<\/h2>\n<p>Transparent Huge Pages (THP) kunnen bestandsgebaseerde pagina's bundelen in grotere eenheden, wat de beheerkosten per pagina vermindert en de TLB ten goede komt wanneer workloads te groot worden, samenhangende <strong>Hoeveelheden<\/strong> passen. In hostingomgevingen met zeer willekeurige toegangen controleer ik het effect zorgvuldig, omdat voordelen niet gegarandeerd zijn. Persistent geheugen belooft daarentegen zeer lage latenties en opent nieuwe datapaden die de klassieke paginacacheflow gedeeltelijk omzeilen. Ik bekijk hier benchmarks en weeg af of de toepassing daadwerkelijk profiteert van de nieuwe geheugenklassen. Vroege experimenten voer ik apart uit van de <strong>Live<\/strong>-Verkeer.<\/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\/2025\/12\/linux-hosting-cache-9481.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Samenvatting: wat ik meeneem<\/h2>\n<p>De Linux Page Cache versnelt hostingworkloads door veelvoorkomende bestandsbewerkingen naar het RAM-geheugen te verplaatsen, waardoor latentie wordt verminderd, de I\/O-belasting wordt verminderd en de <strong>Schalen<\/strong> verbeterd. Ik meet betekenisvolle waarden, herken verkeerde interpretaties bij free -m en gebruik \/proc\/meminfo, vmstat, iostat voor een volledig beeld. Met logrotate, voldoende RAM, zinvolle kernel-limieten en PHP-Opcache verhoog ik de prestaties zonder risicovolle ingrepen. Ik kies bestandssystemen met het oog op toegangsprofielen en observeer IO-Wait om knelpunten tijdig op te lossen. Zo houd ik terugkerende webtoegangen in de cache, ontlast ik de <strong>Geheugen<\/strong>-niveau en lever pagina's snel.<\/p>","protected":false},"excerpt":{"rendered":"<p>Bestandssysteemcaching in Linux-hosting: Linux Page Cache goed begrijpen en serverprestaties maximaliseren.<\/p>","protected":false},"author":1,"featured_media":16414,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-16421","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":"1559","_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":null,"_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 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":"16414","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/16421","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=16421"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/16421\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/16414"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=16421"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=16421"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=16421"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}