{"id":20858,"date":"2026-08-21T11:49:48","date_gmt":"2026-08-21T09:49:48","guid":{"rendered":"https:\/\/webhosting.de\/linux-dirty-ratio-dirty-background-ratio-optimierung-writeback\/"},"modified":"2026-08-21T11:49:48","modified_gmt":"2026-08-21T09:49:48","slug":"linux-dirty-ratio-dirty-background-ratio-optimalisatie-writeback","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/linux-dirty-ratio-dirty-background-ratio-optimierung-writeback\/","title":{"rendered":"Linux Dirty Ratio en Dirty Background Ratio: fijnafstemming voor optimale schrijfprestaties"},"content":{"rendered":"<p>Ik laat zien hoe <strong>linux dirty<\/strong> en de \u2018dirty background ratio\u2019 gebruiken om de paginacache te regelen en zo de schrijfdoorvoer, latentie en gegevensbeveiliging te be\u00efnvloeden. Zo stel je concrete drempelwaarden in die de flusher op tijd activeren, blokkades voorkomen en de schrijfprestaties van je workloads verbeteren.<\/p>\n\n<h2>Centrale punten<\/h2>\n<p>Om te beginnen zal ik de belangrijkste punten kort samenvatten, voordat ik dieper op de materie inga.<\/p>\n<ul>\n  <li><strong>Ongepaste pagina's<\/strong> slaat Writes op in het RAM en bundelt veel kleine toegangsverzoeken tot effici\u00ebntere I\/O-bewerkingen.<\/li>\n  <li><strong>vuile_achtergrond_verhouding<\/strong> start Flusher-threads op de achtergrond en beperkt zo onopgemerkt de hoeveelheid vuil.<\/li>\n  <li><strong>vuile_ratio<\/strong> remt schrijfprocessen af wanneer de harde drempelwaarde wordt overschreden.<\/li>\n  <li><strong>Relatie<\/strong> Beide waarden zijn bepalend voor latentiepieken, doorvoersnelheid en buffergrootte.<\/li>\n  <li><strong>Bytes-varianten<\/strong> (dirty_bytes) bieden op grote servers een nauwkeurigere, absolute controle.<\/li>\n<\/ul>\n\n<h2>Dirty Pages begrijpen<\/h2>\n\n<p>Wanneer een proces gegevens schrijft, komen deze eerst terecht in de <strong>Pagina cache<\/strong> en worden gemarkeerd als \u201edirty\u201c totdat de kernel ze naar de opslagmedia kan doorschrijven. Dit bufferen versnelt de werking van applicaties, omdat RAM sneller reageert dan welke SSD of HDD dan ook en kleine schrijfbewerkingen samenkomen tot grote, sequenti\u00eble overdrachten. Ik houd daarbij altijd in gedachten hoeveel \u201evuil\u201c ik toestaat, want te veel buffering kan wachtrijen verlengen of bij crashes het risico op meer onbeveiligde gegevens vergroten. Wie de werking begrijpt, neemt betere beslissingen over writeback, latentie en opslagdruk. Een kort achtergrondartikel over de <a href=\"https:\/\/webhosting.de\/nl\/writeback-cache-linux-kernelcache\/\">Writeback-cache<\/a> helpt om dit mechanisme duidelijk te begrijpen.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-schreibfeintuning-7492.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Gegevensbeveiliging, fsync en crashvensters<\/h2>\n<p>De grenswaarden be\u00efnvloeden niet alleen de prestaties, maar ook je risicomarge. Ik schat dit met een eenvoudige vuistregel: de maximale hoeveelheid onzekere gegevens gedeeld door de duurzame doorvoersnelheid van het apparaat geeft ruwweg de tijd aan die nodig is totdat de buffer leeg is. Voorbeeld: als ik 4 GB \u2018dirty\u2019 gegevens toestaat en het doelmedium een snelheid van 500 MB\/s haalt, duurt het volledig wegschrijven ongeveer 8 seconden. In die tijd kunnen bij een stroomstoring of kernel-paniek de meest recente schrijfbewerkingen ontbreken.<\/p>\n<p>Toepassingen kunnen het venster via <code>fsync()<\/code> of <code>fdatasync()<\/code> verkleinen, want deze oproepen dwingen het bestandssysteem om gegevens (en, afhankelijk van de journaling-modus, ook metagegevens) naar het medium te schrijven. Dat kost meer, maar is essentieel voor databases of journals. Ik zorg ervoor dat mijn \u2018dirty\u2019-limieten aansluiten bij het synchronisatiegedrag: frequente <code>fsync()<\/code>-Bezoekers profiteren van een lagere <em>vuile_ratio<\/em>, zodat de kernel niet extra afremt als er toch al regelmatig wordt opgeslagen. Omgekeerd mag ik bij logs waarin veel wordt toegevoegd en die zelden worden geleegd, grotere buffers toestaan \u2013 altijd met het oog op het aanvaardbare verliesrisico.<\/p>\n<p>Ook barri\u00e8res en schrijfvolgordes zijn belangrijk: moderne bestandssystemen maken gebruik van FUA\/Flush-commando\u2019s om de caches van de controller correct te legen. Op media zonder Power-Loss-Protection vergroten grote buffers het risico; met PLP of schrijfcachebeveiliging zijn grotere buffers vaak aanvaardbaar.<\/p>\n\n<h2>Dirty Background Ratio: de zachte drempelwaarde<\/h2>\n\n<p>Met <strong>vuile_achtergrond_verhouding<\/strong> Hiermee geef ik aan vanaf welk percentage van de beschikbare opslagruimte flusher-threads op de achtergrond beginnen te schrijven. Deze waarde blokkeert geen toepassingen, maar start stilletjes de opruimwerkzaamheden, zodat de buffer niet uit de hand loopt. Lage waarden zorgen voor vaker, maar gelijkmatiger schrijven op de achtergrond en vlakken latentiepieken af. Hogere waarden laten meer buffering toe, wat bij grote sequenti\u00eble schrijfbewerkingen de doorvoer verhoogt, maar bij plotselinge flushing aanzienlijke I\/O-pieken kan veroorzaken. Standaardwaarden liggen doorgaans rond de tien procent, maar ik pas de grens aan afhankelijk van het medium, de werklast en de veiligheidseisen.<\/p>\n\n<h2>Dirty Ratio: de harde rem<\/h2>\n\n<p>De parameter <strong>vuile_ratio<\/strong> geeft de grens aan waarboven de kernel schrijvende processen afremt totdat er voldoende pagina\u2019s zijn teruggeschreven. Deze harde grens beschermt het geheugen tegen een stortvloed van niet-persistente gegevens en heeft daarmee direct invloed op applicaties zodra deze meer gegevens willen produceren. Bij databases stel ik de waarde eerder laag in, zodat query's constante responstijden behouden en er geen lange flush-fasen ontstaan. Voor back-uptaken gebruik ik daarentegen ruimere buffers om grote blokken effici\u00ebnt over te dragen. Gangbare standaardwaarden vari\u00ebren tussen twintig en veertig procent, maar ik pas dit bereik altijd aan de specifieke belasting aan.<\/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_perf_neu_opt_3847.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Samenwerking en typische relaties<\/h2>\n\n<p>Beide grenswaarden werken als <strong>Tandem<\/strong> en ontplooien hun effect pas samen. Ik houd dirty_background_ratio altijd lager dan dirty_ratio, zodat de kernel op tijd op de achtergrond start en de harde rem zelden in werking treedt. Als vuistregel kies ik vaak een kwart tot de helft van de harde limiet, dus bijvoorbeeld 5\u201310 op 20. Zo start Writeback vroeg genoeg, zonder de doorvoer onnodig te verlagen. Wie deze verhouding niet aanhoudt, krijgt te maken met ofwel te vroege beperking, ofwel te laat achtergrondwerk met merkbare latentiepieken.<\/p>\n\n<h2>Regeling per apparaat en bloklaag-fijnheid<\/h2>\n<p>Naast de algemene limieten is het de moeite waard om ook naar het apparaatniveau te kijken. Linux verdeelt de \u2018dirty load\u2019 over zogenaamde <em>Ondersteunde apparaten<\/em> (bdi). In <code>\/sys\/class\/block\/\/bdi\/<\/code> vind ik parameters zoals <code>max_ratio<\/code>, die bepalen hoeveel van het wereldwijd toegestane \u2018dirty-budget\u2019 een afzonderlijk apparaat mag gebruiken. Op systemen met zowel trage als snelle schijven beperk ik de trage schijven, zodat ze geen knelpunt vormen.<\/p>\n<p>Ook van belang is de beperking op blokniveau via <code>\/sys\/block\/\/queue\/wbt_lat_usec<\/code> (Writeback Throttling). Hiermee streef ik een doellatentie na; de kernel remt de schrijfbelasting af wanneer deze de doeltijd overschrijdt. Bij SATA-HDD's stel ik graag conservatieve waarden in om de interactiviteit te waarborgen. Op zeer snelle NVMe-schijven schakel ik de doellatentie uit of verhoog ik deze, zodat de controller zijn parallelliteit ten volle kan benutten. De I\/O-scheduler (mq-deadline, BFQ, none) kies ik op basis van de situatie: BFQ helpt bij interactieve systemen met een gemengde belasting, terwijl <em>geen<\/em> of dat mq-deadline bij pure doorvoertaakjes op NVMe vaak het beste werkt.<\/p>\n<p>De onderlinge samenwerking is cruciaal: Is <em>vuile_achtergrond_verhouding<\/em> laag, maar omdat het apparaat via WBT agressief wordt beperkt, ontstaan er toch zichtbare opstoppingen. Daarom kalibreer ik beide niveaus samen: globale \u2018dirty\u2019-limieten voor de buffergrootte en de block-layer voor latentiebescherming.<\/p>\n\n<h2>Ratio versus bytes: standaardwaarden en varianten<\/h2>\n\n<p>Op systemen met veel <strong>RAM<\/strong> Procentuele waarden lopen al snel op tot grote absolute grootheden. Dan stel ik liever absolute bovengrenzen in met `dirty_bytes` en `dirty_background_bytes`, om de bufferomvang bijvoorbeeld duidelijk te beperken tot 2\u20138 GB. Dit ontkoppelt de regeling van sterk fluctuerende geheugencapaciteiten en houdt de hoeveelheid niet-persistente gegevens berekenbaar. De keuze blijft dynamisch: voor kleine servers met weinig RAM zijn percentages vaak volstrekt voldoende. Wie over een hoge capaciteit beschikt, kan met bytewaarden vaak beter plannen.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parameters<\/th>\n      <th>Dat betekent<\/th>\n      <th>Standaardinstellingen<\/th>\n      <th>Wanneer moet je dit aanpassen?<\/th>\n      <th>Tip<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>vm.vuile_achtergrond_verhouding<\/td>\n      <td>Start van de <strong>Achtergrond-flush<\/strong> in procenten<\/td>\n      <td>\u2248 10%<\/td>\n      <td>Bij schommelingen in de latentie of bij zeer snelle SSD\u2019s\/NVMe\u2019s<\/td>\n      <td>Lager = gelijkmatiger latentie, hoger = meer buffer<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_ratio<\/td>\n      <td>Hard <strong>Drosselgrens<\/strong> in procenten<\/td>\n      <td>\u2248 20\u201340%<\/td>\n      <td>Bij databases lager, bij back-ups hoger<\/td>\n      <td>Te hoog \u2192 Mogelijke blokkades bij het doorspoelen<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.vuile_achtergrond_bytes<\/td>\n      <td>Start van de achtergrond-flush in <strong>Bytes<\/strong><\/td>\n      <td>Uitgeschakeld wanneer Ratio wordt gebruikt<\/td>\n      <td>Veel RAM, vaste bufferdoelen<\/td>\n      <td>Schakelt Ratio-parameters uit<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_bytes<\/td>\n      <td>Strenge limiet voor de lijster in <strong>Bytes<\/strong><\/td>\n      <td>Uitgeschakeld wanneer Ratio wordt gebruikt<\/td>\n      <td>Veel RAM, een vast te stellen bovengrens<\/td>\n      <td>Schakelt Ratio-parameters uit<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Workload-scenario's en aanbevelingen<\/h2>\n\n<p>Sequenti\u00eble schrijfbelastingen zoals <strong>Back-ups<\/strong> profiteren van grote buffers en matig schrijven op de achtergrond, omdat de kernel in grote blokken naar het medium kan schrijven. Ik stel hier de `dirty_ratio` vaak in tussen 30 en 40 procent en de `dirty_background_ratio` tussen 10 en 20 procent. Databases en kleine random-I\/O-toepassingen gedijen bij voorspelbare latentie, daarom kies ik voor 10\u201315 procent \u2018hard\u2019 en 3\u20135 procent \u2018zacht\u2019. Voor gemengde web- en app-servers blijkt 15\u201320 procent hard en 5\u201310 procent zacht een goed compromis te zijn. Deze marges gelden als uitgangspunt; daarna telt de gemeten realiteit van je systeem.<\/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-schreibperformance-feintuning-5648.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Aspecten van het bestandssysteem en koppelingsopties<\/h2>\n<p>Het writeback-traject eindigt in het bestandssysteem \u2013 de strategie daarvan is bepalend voor de latentie en de beveiliging. Ext4 met <em>data=geordend<\/em> (Standaard) schrijft gebruiksgegevens v\u00f3\u00f3r journal-commits; <em>data=writeback<\/em> verlaagt de latentie, maar brengt oude gegevens in gevaar na crashes. De parameter <code>verbinden=<\/code> (seconden) bepaalt hoe vaak het logboek wordt opgeslagen. Kortere intervallen verminderen gegevensverlies, maar vergen meer I\/O. XFS maakt gebruik van een uitgekiend logboekontwerp; grote <em>logbsgrootte<\/em> en een goede uitlijning helpen bij doorvoertaken. Btrfs bundelt schrijfbewerkingen via \u2018copy-on-write\u2019 \u2013 dit stabiliseert de latentie, maar kan bij kleine willekeurige schrijfbewerkingen en SSD\u2019s met beperkte capaciteit tot fragmentatie leiden. Opties zoals <em>nodatacow<\/em> kunnen helpen bij bepaalde paden of gerichte defragmentatie wanneer er pieken in de latentie optreden.<\/p>\n<p>Ik houd er bovendien rekening mee <em>relatime<\/em>\/<em>noatime<\/em> (beperkt het aantal schrijfbewerkingen op metadata), <em>luiheid<\/em> (mtime\/atime blijven langer behouden) en journaling-barri\u00e8res. Juist bij RAID-controllers of in VM\u2019s is de juiste cache-semantiek van cruciaal belang: verkeerd ingestelde schrijfcaches doen al het werk aan \u2018dirty tuning\u2019 teniet.<\/p>\n\n<h2>Direct I\/O, O_SYNC en het gedrag van de toepassing<\/h2>\n<p>Niet elke aanvraag gaat via de paginacache. Met <code>O_DIRECT<\/code> of <code>O_SYNC<\/code>\/<code>O_DSYNC<\/code> Bepaalde processen omzeilen delen van de cache of vereisen onmiddellijke persistentie. Databases schrijven doorgaans een WAL\/redo-log synchroon en gegevensgebieden asynchroon. Ik stel \u2018dirty\u2019-drempels met name af voor asynchrone paden, terwijl ik voor synchrone paden lage latentie garandeer via snelle journals (NVMe, speciale LUN). Wanneer applicaties zeer vaak <code>fsync()<\/code> bij het oproepen zijn grote buffers niet erg nuttig \u2013 de latentie hangt dan sterker af van de controller, de wachtrijdiepte en de I\/O-scheduler dan van <em>vuile_ratio<\/em>.<\/p>\n\n<h2>Praktische tuning stap voor stap<\/h2>\n\n<p>Voordat ik iets verander, controleer ik de <strong>werkelijke waarden<\/strong> met <code>sysctl vm.dirty_ratio<\/code> en <code>sysctl vm.dirty_background_ratio<\/code>, om de uitgangssituatie vast te leggen. Voor kortdurende tests noteer ik de waarden direct na <code>\/proc\/sys\/vm\/<\/code>bijvoorbeeld <code>echo 15 &gt; \/proc\/sys\/vm\/dirty_ratio<\/code> en <code>echo 5 &gt; \/proc\/sys\/vm\/dirty_background_ratio<\/code>. Als de aanpassing blijvend is, sla ik deze op in <code>\/etc\/sysctl.conf<\/code> of <code>\/etc\/sysctl.d\/*.conf<\/code>. Wijzigingen breng ik aan met <code>sysctl -p<\/code> onmiddellijk, zodat ik het effect snel kan meten. Wie zich verder verdiept in het onderwerp systeemregels, profiteert van praktische tips over de <a href=\"https:\/\/webhosting.de\/nl\/sysctl-optimalisatie-van-de-prestaties-van-webhostingservers\/\">Sysctl-afstemming<\/a> op productieservers.<\/p>\n\n<h2>Waarden afleiden: rekenvoorbeelden<\/h2>\n<p>Ik begin graag met concrete specificaties. Voorbeeld 1: web-\/app-server met 64 GB RAM, NVMe. Het doel is een lage latentie. Ik gebruik <code>dirty_background_bytes=1073741824<\/code> (1 GB) en <code>dirty_bytes=3221225472<\/code> (3 GB). Bij een duurzame NVMe-doorvoersnelheid van 2 GB\/s betekent dit ongeveer 0,5\u20131,5 seconden om te legen \u2013 prima voor interactieve belasting. Voorbeeld 2: back-upknooppunt met 128 GB RAM, snelle SATA-RAID met 800 MB\/s. Ik kies <code>dirty_background_ratio=10<\/code>, <code>dirty_ratio=35<\/code>. In absolute cijfers is dat ongeveer 12,8 GB en 44,8 GB; het duurt 16\u201356 seconden om de RAID leeg te maken. Dat is prima, want de taak is niet interactief.<\/p>\n<p>Voorbeeld 3: Databaseserver met 256 GB RAM, apart journaal op NVMe, gegevens op SSD-array. Ik stel een absolute limiet in om uitschieters te voorkomen: <code>dirty_background_bytes=2147483648<\/code> (2 GB), <code>dirty_bytes=8589934592<\/code> (8 GB). Hierdoor blijft de grootte van het crashvenster voorspelbaar en worden abrupte vertragingen bij checkpoints beperkt.<\/p>\n\n<h2>Writeback-timing en aanverwante parameters<\/h2>\n\n<p>Naast de grenswaarden zijn ook van invloed <strong>Timer<\/strong> het writeback-gedrag en daarmee de gebruikerservaring van de applicaties. Met <code>vm.dirty_writeback_centiseconden<\/code> stel ik het interval in waarin de kernel-flusher wordt geactiveerd, terwijl <code>vm.dirty_expire_centisecs<\/code> bepaalt hoe oud \u2018dirty pages\u2019 maximaal mogen worden. Kortere intervallen zorgen voor frequentere, maar kleinere flushes; langere intervallen besparen I\/O-aanroepen, maar brengen het risico met zich mee dat er grotere bundels ontstaan. Ik pas deze waarden alleen aan als metingen daadwerkelijke nadelen aantonen, zoals te zeldzame flushes op snelle NVMe-schijven. Wie hier methodisch te werk gaat, voorkomt schommelingen tussen te ijverige en te trage writeback-activiteit.<\/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_performance_finetune_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoring en fijnafstelling<\/h2>\n\n<p>Na aanpassingen merk ik het volgende op <strong>continu<\/strong> de kengetallen om successen en bijwerkingen zichtbaar te maken. In <code>\/proc\/meminfo<\/code> controleer ik \u201eDirty\u201c en \u201eWriteback\u201c om de buffercapaciteit en actieve flushes te bekijken. Tools zoals iostat, sar of atop geven me inzicht in doorvoer, wachtrijen en latentietrends. Dit artikel biedt een goede inleiding tot statistieken over <a href=\"https:\/\/webhosting.de\/nl\/server-io-wacht-analyse-iostat-vmstat-metriek-schijf\/\">I\/O-wachttijd analyseren<\/a>. Pas op basis van deze gegevens pas ik de limieten in kleine stapjes aan \u2013 door ze te verlagen of te verhogen \u2013 om te voorkomen dat er onverwachte neveneffecten optreden.<\/p>\n\n<h2>Containers, cgroups en eerlijke verdeling<\/h2>\n<p>In containeromgevingen delen workloads dezelfde kernelmechanismen. Cgroup-Writeback zorgt ervoor dat \u2018dirty pages\u2019 aan de veroorzaker worden toegewezen. Ik gebruik de I\/O-controllers van de cgroups (blkcg) om de bandbreedte of IOPS per container te beperken wanneer individuele tenants te agressief bufferen. Absolute bytelimieten op hostniveau (<em>vuile bytes<\/em>) voorkomen dat \u00e9\u00e9n enkele gast het hele Dirty-budget opslokt. Daarnaast beperk ik de opslagruimte via <code>geheugen.max<\/code>, zodat Writeback niet pas reageert bij een globale druk. Het doel blijft: geen gastbelasting mag leiden tot hostbrede beperkingen van de <em>vuile_ratio<\/em> afdwingen.<\/p>\n\n<h2>Hostingomgevingen en VM's<\/h2>\n\n<p>In multi-tenant-omgevingen en VM\u2019s let ik op <strong>Overboeking<\/strong> van RAM en I\/O, omdat procentuele limieten daar andere gevolgen hebben. Absolute limieten in bytes kunnen voorkomen dat individuele gasten te veel buffer opbouwen en hun buren vertragen. Ik houd rekening met opslagdeduplicatie, ballooning en controllercaches, omdat deze de buffereffecten overstemmen. Voor managed servers loont het als de aanbieder zinvolle standaardinstellingen hanteert, zodat klanten constante responstijden ervaren. Wie zijn eigen knooppunten beheert, profiteert van duidelijk gedefinieerde profielinstellingen per workloadklasse.<\/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\/DirtyRatioTuning1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Veelvoorkomende misverstanden en struikelblokken<\/h2>\n<ul>\n  <li><strong>\u201eMeer buffer = steeds meer doorvoer.\u201c<\/strong> Dit klopt niet bij workloads met veel willekeurige gegevens of apparaten met een kleine wachtrijdiepte. Te grote buffers veroorzaken flush-pieken en wachtrijen.<\/li>\n  <li><strong>\u201edirty_ratio heeft geen invloed op het aantal reads.\u201c<\/strong> Indirect wel: agressieve writeback-fasen verdringen cachepagina\u2019s en verhogen de leeslatenties.<\/li>\n  <li><strong>\u201eBytes en ratio vullen elkaar aan.\u201c<\/strong> Nee. Als je Bytes-varianten gebruikt, heffen deze de bijbehorende Ratio-varianten op. Blijf eenduidig.<\/li>\n  <li><strong>\u201efsync() maakt \u201cdirty limits\u2019 irrelevant.\u201c<\/strong> Nee. Regelmatige synchronisaties verkleinen weliswaar het risicovenster, maar de rest van de belasting valt nog steeds onder de grenswaarden.<\/li>\n  <li><strong>\u201eEen snelle gegevensdrager lost alles op.\u201c<\/strong> Niet als de Block-Layer de snelheid beperkt (WBT) of als het bestandssysteem niet optimaal is gekoppeld.<\/li>\n  <li><strong>\u201eDrop_caches is een tuning-tool.\u201c<\/strong> Het leegmaken van de cache leidt tot vertekende metingen en verergert pieken in de latentie. In de productieomgeving vermijd ik dit.<\/li>\n<\/ul>\n\n<h2>Probleemoplossing: typische symptomen en oplossingen<\/h2>\n\n<p>Stapelen <strong>Pieken in latentie<\/strong>, stel ik eerst de achtergronddrempelwaarde lager in, zodat flushers eerder beginnen en er minder vaak grote schrijfpieken ontstaan. Als applicaties af en toe vastlopen, is de harde limiet meestal te hoog of kan het opslagmedium de ontstane flush-pieken niet aan. In dergelijke gevallen verlaag ik de dirty_ratio, controleer ik de readahead-instellingen en bekijk ik de journaling-opties van het bestandssysteem. Bij zeer snelle NVMe-hardware verhoog ik stapsgewijs de achtergronddrempel, om de doorvoer niet kunstmatig te beperken. Na elke wijziging baseer ik me op de meetresultaten, niet op mijn onderbuikgevoel.<\/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-schreibperformance-5712.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Korte balans voor de praktijk<\/h2>\n\n<p>Met weinig <strong>Stelschroeven<\/strong> Hiermee bepaal ik hoe Linux schrijfgegevens in de buffer opslaat, wanneer de flushers starten en wanneer de kernel het systeem afremt. De \u2018Dirty Background Ratio\u2019 zorgt voor een soepele opschoning, terwijl de \u2018Dirty Ratio\u2019 het RAM-gebruik strenger beperkt. De verhouding tussen beide waarden bepaalt of je systeem eerder gericht is op gelijkmatige latenties of op maximale doorvoer. Ik documenteer de standaardinstellingen, breng in kleine stapjes wijzigingen aan en evalueer de meetresultaten consequent. Zo ontstaat een configuratie die de werklast, het medium en het risico op een verstandige manier in evenwicht brengt en in de praktijk merkbaar sneller werkt.<\/p>","protected":false},"excerpt":{"rendered":"<p>Ontdek hoe je met de \u2018dirty ratio\u2019 en de \u2018dirty background ratio\u2019 in Linux de schrijfprestaties en kernelprestaties van je server gericht kunt optimaliseren en dirty pages effici\u00ebnt kunt beheren.<\/p>","protected":false},"author":1,"featured_media":20851,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20858","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"136","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"linux dirty","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":"20851","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/20858","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=20858"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/20858\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/20851"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=20858"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=20858"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=20858"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}