{"id":20548,"date":"2026-08-11T15:09:51","date_gmt":"2026-08-11T13:09:51","guid":{"rendered":"https:\/\/webhosting.de\/writeback-cache-linux-kernel-cache\/"},"modified":"2026-08-11T15:09:51","modified_gmt":"2026-08-11T13:09:51","slug":"writeback-cache-linux-kernelcache","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/writeback-cache-linux-kernel-cache\/","title":{"rendered":"Inzicht in de writeback-cache en dirty pages in de Linux-kernel"},"content":{"rendered":"<p>De writeback-cache in de Linux-kernel bepaalt wanneer gewijzigde gegevens worden opgeslagen als <strong>Vuile pagina's<\/strong> in het RAM blijven en wanneer de kernel ze gebundeld naar het opslagmedium schrijft. Ik leg uit hoe dit proces <strong>Prestaties<\/strong>, de invloed op latentie en gegevensbeveiliging, en welke regelaars er in de dagelijkse praktijk echt van belang zijn.<\/p>\n\n<h2>Centrale punten<\/h2>\n<ul>\n  <li><strong>Vuile pagina's<\/strong> markeren gewijzigde pagina's in het RAM die nog niet op de gegevensdrager staan.<\/li>\n  <li><strong>Writeback<\/strong> bundelt wijzigingen en schrijft deze effici\u00ebnt in grotere blokken weg.<\/li>\n  <li><strong>Drempelwaarden<\/strong> Net als vm.dirty_ratio bepalen deze instellingen de snelheid en de beperking.<\/li>\n  <li><strong>Synchronisatie<\/strong> Met fsync\/Flush voorkom je gegevensverlies.<\/li>\n  <li><strong>Controle<\/strong> via \/proc en tools worden de belasting en vertragingen weergegeven.<\/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\/linuxserver-writeback-3901.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hoe de paginacache werkt<\/h2>\n\n<p>Ik lees een bestand, de kernel slaat de gegevens op in de paginacache, en latere toegangen worden opgehaald uit de <strong>Geheugen<\/strong> in plaats van vanaf de schijf. Tijdens het schrijven markeert het systeem de gewijzigde pagina's als <strong>Vies<\/strong> en bevestigt de aanroep vaak onmiddellijk, zodat de applicatie blijft draaien. Deze ontkoppeling vermindert wachttijden, omdat trage I\/O-toegangen niet elke app direct vertragen. De cache houdt bovendien veelgebruikte blokken bij de hand en verhoogt de trefkans bij herhaalde toegangen. Wie zich hier verder in wil verdiepen, vindt achtergrondinformatie in mijn overzicht over <a href=\"https:\/\/webhosting.de\/nl\/bestandssysteem-caching-linux-paginacache-cacheboost\/\">Caching van het bestandssysteem<\/a>, waarin de rol van lees- en schrijfpaden in het dagelijks leven wordt ge\u00efllustreerd.<\/p>\n\n<h2>Dirty Pages: betekenis en gevolgen<\/h2>\n\n<p>Dirty Pages zijn gewijzigde geheugenpagina\u2019s die nog niet definitief zijn opgeslagen en dus alleen in het <strong>RAM<\/strong> bestaan. Zolang ze vies zijn, draag ik een zekere <strong>Risico<\/strong>: Een stroomstoring zou deze wijzigingen ongedaan kunnen maken. Toch levert dit een hogere schrijfsnelheid op, omdat de kernel veel kleine updates bundelt. Als het aandeel vervuilde pagina\u2019s toeneemt, neemt de druk op de schrijvers toe. Dan kan het systeem geheugen vrijmaken door de betreffende pagina\u2019s met voorrang naar de schijf te schrijven.<\/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_kernel_meeting_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Writeback: oorzaken en verloop<\/h2>\n\n<p>Writeback wordt gestart op basis van een tijdschema, op basis van een gebeurtenis en op verzoek <strong>Apps<\/strong>. De kernel bundelt \u2018dirty pages\u2019, stelt geschikte I\/O-sequenties samen en stuurt deze via de block-layer naar de <strong>opslagapparaat<\/strong>. Onderweg grijpen bestandssystemen, reclaimers en I\/O-schedulers in om de volgorde en omvang te regelen. Synchronisatieopdrachten zoals fsync zorgen ervoor dat bepaalde gegevens veilig op het medium worden opgeslagen voordat het proces verdergaat. In periodes van hoge activiteit zie ik in de statistieken een stijgend aandeel van writeback, dat na de flush weer daalt.<\/p>\n\n<h2>Interne mechanismen: balance_dirty_pages, BDI en writeback-workers<\/h2>\n\n<p>Onder de motorkap werken verschillende onderdelen op elkaar in. Schrijvende threads doorlopen <strong>balance_dirty_pages()<\/strong>, dat rekening houdt met de huidige \u2018dirty load\u2019, de snelheid van de apparaten en de ingestelde limieten. Het regelt de schrijfsnelheid van de processen (throttling), zodat de achtergrond-writeback dit kan bijhouden. Elk <strong>Ondersteuningsapparaat<\/strong>-Context (bdi) \u2013 doorgaans een blokapparaat of een bestandssysteem-backend \u2013 beschikt over eigen werkwachtrijen met <strong>Flusher-threads<\/strong>, die de Dirty Pages omzetten in geordende I\/O-verzoeken. Deze verdeling voorkomt dat een traag apparaat alle andere vertraagt en zorgt voor een betere verdeling tussen de verschillende workloads.<\/p>\n\n<p>De beperking is adaptief: als ik snellere schrijvers of grotere aaneengesloten gebieden waarneem, stijgen de toegestane \u2018dirty\u2019-hoeveelheden tijdelijk. Bij opstoppingen, hoge latenties of verzadigde wachtrijen treedt de kernel agressiever in en dwingt hij schrijvers tot pauzes, totdat de buffer weer wat ruimte heeft. Juist deze wisselwerking verklaart waarom kleine parameterwijzigingen tot merkbaar andere latentieprofielen kunnen leiden.<\/p>\n\n<h2>Drempelwaarden: vm.dirty_background_ratio en vm.dirty_ratio<\/h2>\n\n<p>Ik stuur het gedrag aan met twee belangrijke grenzen, die het aandeel vervuilde pagina\u2019s ten opzichte van de <strong>RAM<\/strong> defini\u00ebren. Als ik de drempelwaarde overschrijd, begint de kernel in de <strong>Achtergrond<\/strong> schrijven. Als ik de harde limiet bereik, remt het systeem de schrijvende processen af totdat er voldoende gegevens zijn teruggespoeld. Zo blijft het geheugen bruikbaar, zelfs als afzonderlijke programma\u2019s grote hoeveelheden wijzigingen genereren. Wie met op bytes gebaseerde limieten werkt, stelt de bijbehorende *_bytes-parameters in in plaats van de ratio-waarden.<\/p>\n\n<h2>Tabel: Relevante kernelparameters en kengetallen<\/h2>\n\n<p>Ik gebruik een aantal centrale schakelaars om writeback, latentie en doorvoersnelheid gericht te regelen en zichtbaar te maken; het volgende overzicht helpt bij het <strong>Classificatie<\/strong> en snelle <strong>Examen<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parameter\/indicator<\/th>\n      <th>Effect<\/th>\n      <th>Startwaarden\/Opmerking<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>vm.dirty_background_ratio \/ vm.dirty_background_bytes<\/td>\n      <td>Start achtergrond-writeback wanneer het percentage vervuilde pagina's deze drempelwaarde overschrijdt.<\/td>\n      <td>Kies voor servers liever een conservatieve instelling, zodat de flush eerder wordt gestart.<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_ratio \/ vm.dirty_bytes<\/td>\n      <td>Bovengrens voor \u2018dirty pages\u2019; vanaf dit punt worden schrijvers afgeremd.<\/td>\n      <td>Te hoog verhoogt het risico op vertraging, te laag gaat ten koste van de doorvoercapaciteit.<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_writeback_centiseconden<\/td>\n      <td>Interval waarin de kernel controleert of er \u2018dirty pages\u2019 zijn voor het op de achtergrond leegmaken van het cachegeheugen.<\/td>\n      <td>Kleinere intervallen zorgen ervoor dat pieken in de belasting worden afgevlakt, maar leiden tot meer wake-ups.<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_expire_centisecs<\/td>\n      <td>Leeftijd vanaf wanneer Dirty Pages als \u201erijp\u201c worden beschouwd en bij voorkeur worden geschreven.<\/td>\n      <td>Hogere waarden zorgen voor een sterkere bundeling, maar verminderen de consistentiegaranties in geval van fouten.<\/td>\n    <\/tr>\n    <tr>\n      <td>\/proc\/meminfo: Dirty, Writeback<\/td>\n      <td>Huidig aantal vervuilde of actief teruggedraaide pagina's.<\/td>\n      <td>Handig voor live-observatie tijdens belastingstests.<\/td>\n    <\/tr>\n    <tr>\n      <td>Mount-\/FS-opties (bijv. barri\u00e8res, journaalmodus)<\/td>\n      <td>Be\u00efnvloeden de volgorde, de persistentie en de kosten van afzonderlijke flushes.<\/td>\n      <td>Kies afhankelijk van het bestandssysteem en het apparaat de juiste optie.<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Ik lees deze waarden regelmatig uit en breng ze in verband met I\/O-wachttijden in Top, iostat of soortgelijke programma\u2019s <strong>Gereedschap<\/strong>. Dit geeft een duidelijk beeld van de vraag of Writeback zelf beperkt is of dat het <strong>Opslag<\/strong> op het randje ligt.<\/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-kernel-cache-dirty-pages-4827.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoring en diagnose: wat ik meet<\/h2>\n\n<p>Ik controleer eerst \/proc\/meminfo en houd de velden \u201eDirty\u201d en \u201eWriteback\u201d in de gaten, terwijl ik gericht <strong>Belasting<\/strong> produceer. Als de \u2018dirty\u2019 sterk stijgen en hoog blijven, ontbreken vaak tijdige flushes of het <strong>Medium<\/strong> is volledig bezet. Als Writeback toeneemt, maar Dirty slechts langzaam afneemt, remt het doelapparaat of het I\/O-pad af. Als latentiepieken samenvallen met Writeback-pieken, pas ik het interval aan of verlaag ik de ratio-waarden. Om inzicht te krijgen in typische patronen, helpt een korte <a href=\"https:\/\/webhosting.de\/nl\/linux-paginacache-prestatieverbeteraar\/\">Page-Cache-Booster<\/a>, waarin de praktische stelschroeven en meetpunten zijn samengevat.<\/p>\n\n<h2>Uitgebreide meetpunten, vmstat en tracering<\/h2>\n\n<p>Naast \/proc\/meminfo maak ik gebruik van zeer gedetailleerde tellers om oorzaak en gevolg van elkaar te scheiden. In <strong>\/proc\/vmstat<\/strong> Velden zoals nr_dirty, nr_writeback, nr_dirtied en nr_written geven inzicht in de dynamiek: hoe snel raakt het systeem vervuild, hoe snel wordt het schoongemaakt? Daarnaast houd ik de lengte van de I\/O-wachtrijen en de afbrekingspercentages voor merge-bewerkingen in de blocklayer in de gaten.<\/p>\n\n<ul>\n  <li>vmstat 1: toont per seconde de drift van dirty\/writeback en IO-wachttijd (wa),<\/li>\n  <li>\/proc\/pressure\/memory: geeft de geheugendruk weer die indirect writeback activeert,<\/li>\n  <li>Tracepoints (writeback:*) en blokgebeurtenissen: geven de volgorde en omvang van de flushes weer,<\/li>\n  <li>perf\/ftrace: identificeert hotspots in balance_dirty_pages en Flusher-werkwachtrijen.<\/li>\n<\/ul>\n\n<p>Als ik zie dat nr_dirtied constant hoger is dan nr_written, is dat een duidelijk teken van dreigende throttling of te late achtergrond-flushes. Als pieken in de writeback-tracepoints samenvallen met latentiepieken, optimaliseer ik het interval en de batchgroottes.<\/p>\n\n<h2>HDD versus SSD: gevolgen voor het writeback-ontwerp<\/h2>\n\n<p>Op roterende platen leveren grotere, aaneengesloten flushes bijzonder veel op, omdat ze duur zoeken <strong>Vermijd<\/strong>. SSD\u2019s profiteren hier ook van, maar wat hier telt is de verdeling van de schrijfbewerkingen en de interactie met de <strong>Controller<\/strong>. Ik voorkom een overmatig aantal kleine synchronisaties, zodat de firmware effici\u00ebnt kan werken. Tegelijkertijd let ik bij SSD\u2019s steeds meer op consistentiebarri\u00e8res en flush-semantiek om echt optimaal gebruik te maken van de garanties van het apparaat. Gemengde workloads met willekeurige lees- en schrijfbewerkingen reageren merkbaar op kleine aanpassingen in de \u2018dirty\u2019-drempels en de flush-timing.<\/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\/tech_office_nacht_6342.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Apparaatcache, flush-semantiek en bescherming tegen stroomuitval (PLP)<\/h2>\n\n<p>Of een flush daadwerkelijk wordt opgeslagen, hangt ook af van de <strong>Apparaatcache<\/strong> . Veel schijven slaan gegevens tijdelijk op in hun eigen DRAM. Zonder <strong>Bescherming tegen stroomverlies (PLP)<\/strong> loop ik het risico op gegevensverlies als de cache niet op tijd wordt geleegd. Writeback maakt weliswaar gebruik van de apparaatcache, maar ik zorg ervoor dat barri\u00e8res en flush-opdrachten worden gerespecteerd. Op systemen met RAID-controllers beoordeel ik of er een batterij- of flash-geback-upte cache aanwezig is; in dat geval zijn gesynchroniseerde schrijfbewerkingen vaak gunstiger, zonder dat dit ten koste gaat van de veiligheid.<\/p>\n\n<p>Ik maak bovendien het volgende onderscheid: FUA (Force Unit Access) dwingt persistentie per I\/O af, maar kost wel IOPS. Flush-barri\u00e8res kunnen meerdere schrijfbewerkingen tegelijkertijd vastleggen. Voor bijzonder kritieke paden (zoals journaals) accepteer ik de FUA\/flush-overhead, terwijl ik bulkgegevens in de writeback-stream laat staan. Wie mount-opties of controllerinstellingen wijzigt, controleert vervolgens met belastingstests of de beoogde flush-semantiek werkt.<\/p>\n\n<h2>Gegevensconsistentie: fsync, flush en FUA correct gebruiken<\/h2>\n\n<p>Ik gebruik fsync specifiek voor gegevens met een hoge <strong>Waarde<\/strong>, die een duidelijke duurzaamheidsgarantie nodig hebben. De kernel kan flush-bewerkingen doorvoeren tot op het opslagmedium en met FUA eisen dat een schrijfbewerking daadwerkelijk <strong>blijft bestaan<\/strong>, voordat de bevestiging terugkomt. Deze aanpak kost tijd en IOPS, maar voorkomt gegevensverlies bij systeemcrashes. Zonder dergelijke barri\u00e8res meldt het systeem dat de bewerking is geslaagd, terwijl de bytes nog in de cache van de SSD of in het RAM-geheugen staan. Ik stem deze beslissingen af op de toepassing: transactielogboeken worden hard opgeslagen, bulk-updates zacht.<\/p>\n\n<h2>Voorbeelden van optimalisatie voor hosting- en databaseworkloads<\/h2>\n\n<p>Voor web- en databaseservers stel ik vaak een gematigde `dirty_background_ratio` in en houd ik `dirty_ratio` aanzienlijk hoger, zodat de achtergrondflush tijdig plaatsvindt <strong>start<\/strong>, zonder Schreiber te vroeg te <strong>Rem<\/strong>. Bij schrijfpieken verlaag ik het writeback-interval, zodat de writeback-processen eerder in werking treden. Op systemen met veel RAM geef ik de voorkeur aan *_bytes-waarden, zodat er met werkelijke grootheden in plaats van percentages wordt gewerkt. Ik test elke wijziging met herhaalbare benchmarks en meet de latentie, doorvoer en 95-\/99-percentielen. Dit praktijkgerichte overzicht biedt mij een beknopte handleiding over het effect van de paginacache: <a href=\"https:\/\/webhosting.de\/nl\/linux-paginacache-prestatieverbeteraar\/\">Prestatieverbeteraar voor de Linux-paginacache<\/a>.<\/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\/devdesk_linux_cache_4732.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Direct I\/O en mmap: wanneer de paginacache wordt omzeild<\/h2>\n\n<p>Niet elke toepassing maakt op dezelfde manier gebruik van de paginacache. Met <strong>O_DIRECT<\/strong> kan het de cache bewust omzeilen en rechtstreeks naar het apparaat schrijven of daaruit lezen. Dat ontlast het RAM-geheugen en verkort de paden, maar ontneemt mij de voordelen van batching en readahead. Voor grote, eenmalige overdrachten kan dat zinvol zijn; bij veel kleine schrijfbewerkingen gaan de voordelen van writeback daarentegen verloren.<\/p>\n\n<p>Met <strong>mmap<\/strong> en bij Copy-on-Write markeer ik pagina\u2019s bij wijzigingen als \u2018dirty\u2019; het flushen gebeurt via het normale writeback-pad of door <strong>msync<\/strong>. Ik houd hier rekening mee wanneer applicaties intensief gebruikmaken van memory-mapped I\/O: er kunnen onverwachte pieken in het aantal \u201edirty\u201c gegevens optreden, ook al schrijft de app \u2018alleen maar\u2019 naar het geheugen. Ook hier helpen ratio- en byte-limieten om het tijdstip van het terugschrijven te regelen.<\/p>\n\n<h2>Containeromgevingen en cgroup-writeback<\/h2>\n\n<p>In multi-tenant-omgevingen voorkom ik \u201eNoisy Neighbors\u201c door middel van <strong>cgroups<\/strong>. De kernel wijst \u2018dirty pages\u2019 toe aan de groep die ze heeft veroorzaakt (cgroup-writeback), zodat \u2018background flush\u2019 en \u2018throttling\u2019 eerlijker worden verdeeld. Met geheugenlimieten (<strong>geheugen.hoog<\/strong>, memory.max) beperk ik het aantal \u2018dirty-pieken\u2019 per container. Daarnaast stel ik I\/O-quota\u2019s in via de I\/O-controller, om te voorkomen dat afzonderlijke workloads de volledige wachtrij van het apparaat vullen.<\/p>\n\n<p>In de praktijk stel ik per serviceklasse realistische bovengrenzen vast: batch-taken met een hoge schrijfbelasting krijgen ruime \u2018dirty-budgetten\u2019, terwijl frontends waarbij latentie cruciaal is, krappere budgetten krijgen. Zo blijft de totale latentie stabieler, omdat Writeback niet plotseling voor iedereen afremt zodra \u00e9\u00e9n enkele container uit de pas loopt.<\/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-kernel-cache-8974.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Netwerkbestandssystemen (NFS, SMB, gedistribueerde bestandssystemen)<\/h2>\n\n<p>Bij netwerkbestandssystemen komt er nog een bufferlaag bij. Lokale \u2018dirty pages\u2019 geven alleen aan dat er gegevens onderweg zijn; of ze <strong>op afstand<\/strong> Of gegevens worden opgeslagen, wordt bepaald door het protocol (commit-semantiek) en de server. Ik vertrouw niet op impliciete flushes: kritieke gegevens synchroniseer ik expliciet. Tegelijkertijd houd ik rekening met de round-trip-kosten \u2013 te frequente synchronisaties via het netwerk verslechteren de latentie merkbaar.<\/p>\n\n<p>Bij gemengde workloads splits ik de paden op: lokale, tijdelijke bestanden profiteren maximaal van de paginacache; netwerkkoppelingen krijgen strengere synchronisatiepunten. Zo voorkom ik dat writeback via het netwerk een bottleneck wordt, terwijl lokale taken nog reserves zouden hebben.<\/p>\n\n<h2>I\/O-scheduler, blk-mq en wachtrijdiepte<\/h2>\n\n<p>Hoe effici\u00ebnt writeback-batches op het apparaat terechtkomen, hangt ook af van de <strong>Blocklayer<\/strong> vanaf. Met <strong>blk-mq<\/strong> I\/O's worden over meerdere wachtrijen verdeeld; schedulers zoals mq-deadline of kyber stellen prioriteiten en rangschikken ze. Ik kies de scheduler op basis van het medium: op NVMe is \u201enone\u201c vaak zinvol, bij SATA of SAS helpt Deadline bij het rangschikken van schrijfbewerkingen.<\/p>\n\n<p>De <strong>Diepte wachtrij<\/strong> Ik stel dit zo in dat het apparaat volledig wordt benut, maar niet overbelast raakt. Een te lage diepte leidt tot verlies van doorvoer, een te hoge diepte vergroot de variatie in latentie en maakt throttling lastig. Writeback profiteert van gematigde dieptes en grote, aaneengesloten verzoeken. Ik houd de merge-percentages en de \u201einflight\u201c-tellers in de gaten; dalende merge-percentages duiden op te kleine batches of concurrerende willekeurige workloads.<\/p>\n\n<h2>Reproduceerbare tests en veilige terugdraaiing<\/h2>\n\n<p>Voordat ik de regelaars verstel, leg ik de huidige toestand vast en test ik <strong>Reproduceerbaar<\/strong> en plan terugsprongen. Ik gebruik identieke workloads en identieke hoeveelheden gegevens, en warm de cache doelgericht op of leeg hem bewust om testruns vergelijkbaar te maken. Wijzigingen in de instellingen pas ik eerst tijdelijk toe, observeer de statistieken en pas daarna pas definitief op.<\/p>\n\n<pre><code># Voorbeeld: tijdelijke afstemmingsstappen (Root)\nsysctl -w vm.dirty_background_bytes=$((512*1024*1024))\nsysctl -w vm.dirty_bytes=$((2*1024*1024*1024))\nsysctl -w vm.dirty_writeback_centisecs=100\nsysctl -w vm.dirty_expire_centisecs=3000\n\n# Korte belastingstest (voorbeeld, afhankelijk van de workload)\n# fio --name=wbtest --filename=\/data\/testfile --size=8G --ioengine=libaio \\\n#     --rw=randwrite --bs=128k --iodepth=32 --direct=0 --numjobs=4 --runtime=60 --time_based\n<\/code><\/pre>\n\n<p>Ondertussen lees ik \/proc\/meminfo, vmstat en iostat tegelijkertijd uit en breng ik pieken in verband met elkaar. Na de test zet ik de waarden terug of neem ik ze op een gecontroleerde manier over in de systeemconfiguratie. Daartoe documenteer ik <strong>datum<\/strong>, <strong>Kernel<\/strong>-versie, apparaat- en bestandssysteemgegevens, zodat latere vergelijkingen betrouwbaar blijven.<\/p>\n\n<h2>Veelvoorkomende problemen en oplossingen<\/h2>\n\n<p>Als het systeem soepel lijkt te werken, maar schrijfbewerkingen vastlopen, controleer ik of er sprake is van throttling door een te lage <strong>vuile_ratio<\/strong>. Als Dirty op een hoog niveau blijft, ontbreekt er bandbreedte of het <strong>Interval<\/strong> is te lang voor de flush. Als de latentie bij korte sync-pieken explosief toeneemt, verdeel ik de belasting over kleinere batches en zorg ik voor een betere I\/O-planning. Als de cache nauwelijks op gang komt, kan een te lage *_bytes-limiet zinvolle batchverwerking in de weg staan. Een nadere blik op <a href=\"https:\/\/webhosting.de\/nl\/server-pagina-cache-eviction-linux-geheugen-print-optimalisatie-inzicht\/\">Cache-eviction bij afdrukken<\/a> helpt als er ook nog eens een tekort aan opslagruimte is.<\/p>\n\n<h2>Beste praktijken en korte checklist<\/h2>\n\n<p>Ik maak een strikt onderscheid tussen gegevens die onmiddellijk moeten worden opgeslagen en gegevens die pas later hoeven te worden opgeslagen, om <strong>Prestaties<\/strong> te winnen. Voor logbestanden en transactiejournaals dwing ik synchronisaties af; voor tijdelijke artefacten laat ik writeback vrij verlopen en houd ik alleen de beperkingslimiet in de gaten. Voor elke aanpassing meet ik de huidige toestand en vergelijk ik A\/B aan de hand van gedefinieerde scenario\u2019s. Ik houd het aantal gelijktijdige schrijvers binnen de perken, omdat ongeco\u00f6rdineerde pieken het nut van batchverwerking verminderen. En ik documenteer wijzigingen onmiddellijk, zodat toekomstige analyses kunnen steunen op duidelijke <strong>Gegevens<\/strong> gebaseerd.<\/p>\n\n<h2>Praktische samenvatting voor snel succes<\/h2>\n\n<p>De writeback-cache bundelt wijzigingen in de <strong>Pagina<\/strong> Cache verlaagt de I\/O-kosten en ontlast applicaties. Dirty pages zijn geen fout, maar een doelgericht middel om snelheid te winnen, zolang ik de limieten en de consistentie-eisen ken. Met de parameters vm.dirty_background_ratio en vm.dirty_ratio regel ik wanneer de kernel stilletjes op de achtergrond werkt en wanneer hij schrijfbewerkingen afremt. Tools en \/proc geven me het nodige inzicht in 'dirty' en 'writeback', zodat ik niet in het duister tast. Als ik deze instellingen onder de knie heb, draaien het web, databases en batch-taken meetbaar sneller, zonder dat de <strong>Integriteit<\/strong> mijn gegevens in gevaar te brengen.<\/p>","protected":false},"excerpt":{"rendered":"<p>Writeback-cache in de Linux-kernel: dirty pages, paginacache en terugschrijven op een begrijpelijke manier uitgelegd.<\/p>","protected":false},"author":1,"featured_media":20541,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20548","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":"150","_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":"Writeback 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":"20541","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/20548","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=20548"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/20548\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/20541"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=20548"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=20548"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=20548"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}