{"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-optimering-writeback","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/linux-dirty-ratio-dirty-background-ratio-optimierung-writeback\/","title":{"rendered":"Linux Dirty Ratio og Dirty Background Ratio: Finjustering for optimal skriveydelse"},"content":{"rendered":"<p>Jeg viser, hvordan <strong>linux dirty<\/strong> og styre sidecachen ved hj\u00e6lp af dirty background ratio og dermed p\u00e5virke skrivegennemstr\u00f8mning, latenstid og datasikkerhed. P\u00e5 den m\u00e5de fastl\u00e6gger du konkrete gr\u00e6nsev\u00e6rdier, der s\u00f8rger for, at flusherne startes i tide, undg\u00e5r blokeringer og \u00f8ger skriveydelsen for dine arbejdsbelastninger.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<p>Indledningsvis vil jeg kort opsummere de vigtigste pointer, inden jeg g\u00e5r mere i dybden.<\/p>\n<ul>\n  <li><strong>Uanst\u00e6ndige sider<\/strong> bufferer Writes i RAM og samler mange sm\u00e5 adgangsforesp\u00f8rgsler til mere effektive I\/O-operationer.<\/li>\n  <li><strong>dirty_background_ratio<\/strong> starter Flusher-tr\u00e5de i baggrunden og begr\u00e6nser dermed m\u00e6ngden af snavs, uden at man l\u00e6gger m\u00e6rke til det.<\/li>\n  <li><strong>dirty_ratio<\/strong> bremser skrivende processer, hvis den faste gr\u00e6nsev\u00e6rdi overskrides.<\/li>\n  <li><strong>Relation<\/strong> Begge v\u00e6rdier er afg\u00f8rende for spidsbelastninger, gennemstr\u00f8mning og bufferst\u00f8rrelse.<\/li>\n  <li><strong>Bytes-varianter<\/strong> (dirty_bytes) giver mulighed for mere pr\u00e6cis og fuldst\u00e6ndig kontrol p\u00e5 store servere.<\/li>\n<\/ul>\n\n<h2>At forst\u00e5 \u00bbDirty Pages\u00ab<\/h2>\n\n<p>N\u00e5r en proces skriver data, havner de f\u00f8rst i <strong>Side-cache<\/strong> og markeres som \u201edirty\u201c, indtil kernen kan skrive dem til lagringsmediet. Denne buffering fremskynder applikationerne, fordi RAM reagerer hurtigere end enhver SSD eller HDD, og sm\u00e5 skrivninger samles til store, sekventielle overf\u00f8rsler. Jeg holder altid \u00f8je med, hvor meget \u201esnavs\u201c jeg tillader, for for meget buffering kan forl\u00e6nge k\u00f8erne eller medf\u00f8re en st\u00f8rre risiko for ubeskyttede data i tilf\u00e6lde af nedbrud. Den, der forst\u00e5r, hvordan det fungerer, kan tr\u00e6ffe bedre beslutninger om writeback, latenstid og lagerbelastning. En kort baggrundsartikel om <a href=\"https:\/\/webhosting.de\/da\/writeback-cache-linux-kernel-cache\/\">Writeback-cache<\/a> hj\u00e6lper med at placere denne mekanisme i den rette sammenh\u00e6ng.<\/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>Datasikkerhed, fsync og nedbrudsvindue<\/h2>\n<p>Gr\u00e6nsev\u00e6rdierne p\u00e5virker ikke kun ydeevnen, men ogs\u00e5 dit risikovindue. Jeg beregner det groft ved hj\u00e6lp af en simpel tommelfingerregel: den maksimale m\u00e6ngde usikre data divideret med enhedens vedvarende gennemstr\u00f8mning giver groft sagt den tid, det tager, indtil bufferen er tom. Eksempel: Hvis jeg tillader 4 GB \"dirty data\", og m\u00e5lmediet n\u00e5r 500 MB\/s, tager den fuldst\u00e6ndige overskrivning cirka 8 sekunder. I dette tidsrum kan de seneste skrivninger g\u00e5 tabt i tilf\u00e6lde af str\u00f8msvigt eller kernel-panik.<\/p>\n<p>Programmer kan lukke vinduet ved at <code>fsync()<\/code> eller <code>fdatasync()<\/code> begr\u00e6nse, da disse adgangsforesp\u00f8rgsler tvinger filsystemet til at skrive data (og, afh\u00e6ngigt af journaliseringsmodus, ogs\u00e5 metadata) til mediet. Det er mere ressourcekr\u00e6vende, men afg\u00f8rende for databaser eller journaler. Jeg s\u00f8rger for, at mine \u00bbdirty\u00ab-gr\u00e6nser passer til synkroniseringsadf\u00e6rden: Hyppige <code>fsync()<\/code>-Visninger drager fordel af lavere <em>dirty_ratio<\/em>, s\u00e5 kernen ikke begr\u00e6nser ydeevnen yderligere, n\u00e5r der alligevel sker regelm\u00e6ssig lagring. Omvendt kan jeg tillade st\u00f8rre buffere ved logfiler, der hovedsageligt bruger \u00bbappend\u00ab-funktioner og sj\u00e6ldent t\u00f8mmes \u2013 altid med tanke p\u00e5 den accepterede risiko for tab.<\/p>\n<p>Barrierer og skriver\u00e6kkef\u00f8lger er ogs\u00e5 vigtige: Moderne filsystemer bruger FUA\/Flush-kommandoer til at t\u00f8mme controller-cacher korrekt. P\u00e5 medier uden Power-Loss-Protection \u00f8ger store buffere risikoen; med PLP eller skrivecache-beskyttelse er st\u00f8rre buffere ofte acceptable.<\/p>\n\n<h2>Dirty Background Ratio: den bl\u00f8de t\u00e6rskelv\u00e6rdi<\/h2>\n\n<p>Med <strong>dirty_background_ratio<\/strong> Her angiver jeg, fra hvilken procentdel af den tilg\u00e6ngelige lagerplads flusher-tr\u00e5de begynder at skrive i baggrunden. Denne v\u00e6rdi blokerer ikke applikationer, men starter stille og roligt oprydningsarbejdet, s\u00e5 bufferen ikke l\u00f8ber l\u00f8bsk. Lave tal medf\u00f8rer hyppigere, men mere j\u00e6vn skrivning i baggrunden og udj\u00e6vner latenstops. H\u00f8jere tal tillader st\u00f8rre buffere, hvilket \u00f8ger gennemstr\u00f8mningen ved store sekventielle skrivninger, men kan udl\u00f8se betydelige I\/O-spidsbelastninger ved pludselig flush. Standardv\u00e6rdierne ligger typisk omkring ti procent, men jeg justerer gr\u00e6nsen afh\u00e6ngigt af medie, arbejdsbelastning og sikkerhedskrav.<\/p>\n\n<h2>Dirty Ratio: den h\u00e5rde opbremsning<\/h2>\n\n<p>Parameteren <strong>dirty_ratio<\/strong> markerer den gr\u00e6nse, hvor kernelen begr\u00e6nser skrivende processer, indtil der er skrevet nok sider tilbage. Denne faste gr\u00e6nse beskytter hukommelsen mod en str\u00f8m af ikke-persisterede data og p\u00e5virker dermed direkte applikationerne, s\u00e5 snart de \u00f8nsker at forts\u00e6tte med at producere data. For databaser indstiller jeg v\u00e6rdien ret lavt, s\u00e5 foresp\u00f8rgsler bevarer konstante svarstider, og der ikke opst\u00e5r lange flush-faser. Til backup-opgaver bruger jeg derimod mere gener\u00f8se buffere for at overf\u00f8re store blokke effektivt. De s\u00e6dvanlige standardv\u00e6rdier varierer mellem tyve og fyrre procent, men jeg tilpasser altid dette interval til den konkrete belastning.<\/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>Samspil og typiske relationer<\/h2>\n\n<p>Begge gr\u00e6nsev\u00e6rdier fungerer som <strong>Tandem<\/strong> og udfolder f\u00f8rst deres virkning i kombination. Jeg holder altid dirty_background_ratio lavere end dirty_ratio, s\u00e5 kernen starter i baggrunden i tide, og den h\u00e5rde bremse sj\u00e6ldent tr\u00e6der i kraft. Som tommelfingerregel v\u00e6lger jeg ofte en fjerdedel til halvdelen af den h\u00e5rde gr\u00e6nse, alts\u00e5 for eksempel 5\u201310 til 20. P\u00e5 den m\u00e5de starter Writeback tilstr\u00e6kkeligt tidligt uden at reducere gennemstr\u00f8mningen un\u00f8digt. Hvis man ikke overholder dette forhold, oplever man enten for tidlig begr\u00e6nsning eller for sen baggrundsbehandling med m\u00e6rkbare forsinkelsestoppe.<\/p>\n\n<h2>Styring pr. enhed og bloklagsfinhed<\/h2>\n<p>Ud over de globale begr\u00e6nsninger er det v\u00e6rd at se n\u00e6rmere p\u00e5 enhedsniveauet. Linux fordeler \u00bbdirty-load\u00ab via s\u00e5kaldte <em>Underst\u00f8ttede enheder<\/em> (bdi). I <code>\/sys\/class\/block\/\/bdi\/<\/code> Jeg synes, at parametre som <code>max_ratio<\/code>, som bestemmer, hvor stor en del af det samlede tilladte \u00bbdirty-budget\u00ab et enkelt enhed m\u00e5 tr\u00e6kke p\u00e5. P\u00e5 systemer med b\u00e5de langsomme og hurtige drev begr\u00e6nser jeg de langsomme drev, s\u00e5 de ikke bliver flaskehalsen.<\/p>\n<p>Lige s\u00e5 relevant er begr\u00e6nsningen af block-lag via <code>\/sys\/block\/\/queue\/wbt_lat_usec<\/code> (Writeback Throttling). Hermed sigter jeg mod en m\u00e5llatens; kernen begr\u00e6nser derefter skrivebelastningen, n\u00e5r denne overskrider m\u00e5ltiden. P\u00e5 SATA-harddiske indstiller jeg gerne konservative v\u00e6rdier for at beskytte interaktiviteten. P\u00e5 meget hurtige NVMe-drev deaktiverer eller \u00f8ger jeg m\u00e5llatensen, s\u00e5 controlleren kan udnytte sin parallelitet fuldt ud. Jeg v\u00e6lger I\/O-scheduleren (mq-deadline, BFQ, none) efter behov: BFQ er en fordel i interaktive systemer med blandet belastning, mens <em>ingen<\/em> eller at mq-deadline ofte fungerer bedst ved rene gennemstr\u00f8mningsopgaver p\u00e5 NVMe.<\/p>\n<p>Samspillet er afg\u00f8rende: Er <em>dirty_background_ratio<\/em> Selvom v\u00e6rdien er lav, men enheden begr\u00e6nses aggressivt via WBT, opst\u00e5r der alligevel synlige flaskehalse. Derfor kalibrerer jeg begge niveauer sammen \u2013 globale \u00bbdirty-limits\u00ab for bufferst\u00f8rrelse og bloklag for latensbeskyttelse.<\/p>\n\n<h2>Ratio vs. bytes: Standardv\u00e6rdier og varianter<\/h2>\n\n<p>P\u00e5 systemer med stor <strong>RAM<\/strong> Procentv\u00e6rdier vokser hurtigt til store absolutte st\u00f8rrelsesordener. I s\u00e5 fald foretr\u00e6kker jeg at indf\u00f8re absolutte \u00f8vre gr\u00e6nser med `dirty_bytes` og `dirty_background_bytes` for klart at begr\u00e6nse bufferst\u00f8rrelsen til ca. 2\u20138 GB. Dette adskiller reguleringen fra st\u00e6rkt svingende hukommelsesudvidelsesniveauer og holder m\u00e6ngden af ikke-persisterede data forudsigelig. Valget forbliver dynamisk: For sm\u00e5 servere med lidt RAM er procenter ofte helt tilstr\u00e6kkelige. Hvis man har stor kapacitet, er det ofte lettere at planl\u00e6gge med byte-v\u00e6rdier.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parametre<\/th>\n      <th>Betydning<\/th>\n      <th>Typiske standardindstillinger<\/th>\n      <th>Hvorn\u00e5r skal man skifte?<\/th>\n      <th>Hint<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>vm.dirty_background_ratio<\/td>\n      <td>Start af <strong>Baggrunds-flush<\/strong> i procent<\/td>\n      <td>\u2248 10%<\/td>\n      <td>Ved svingninger i latenstiden eller meget hurtige SSD\/NVMe-drev<\/td>\n      <td>Lavere = j\u00e6vnere latenstid, h\u00f8jere = st\u00f8rre buffer<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_ratio<\/td>\n      <td>H\u00e5rd <strong>Drosselgr\u00e6nse<\/strong> i procent<\/td>\n      <td>\u2248 20\u201340%<\/td>\n      <td>Lavere for databaser, h\u00f8jere for sikkerhedskopier<\/td>\n      <td>For h\u00f8j \u2192 Der kan opst\u00e5 blokeringer ved flush<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_background_bytes<\/td>\n      <td>Start af baggrunds-flush i <strong>Bytes<\/strong><\/td>\n      <td>Deaktiveret, n\u00e5r Ratio anvendes<\/td>\n      <td>Stor RAM, faste bufferm\u00e5l<\/td>\n      <td>Overskriver Ratio-parametre<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_bytes<\/td>\n      <td>Streng gr\u00e6nse for tr\u00e6kfugle i <strong>Bytes<\/strong><\/td>\n      <td>Deaktiveret, n\u00e5r Ratio anvendes<\/td>\n      <td>Stor RAM, fastsat \u00f8vre gr\u00e6nse<\/td>\n      <td>Overskriver Ratio-parametre<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Arbejdsbelastningsscenarier og anbefalinger<\/h2>\n\n<p>Sekventielle skrivebelastninger som f.eks. <strong>Sikkerhedskopier<\/strong> drager fordel af store buffere og moderat baggrundsskrivning, fordi kernen i store tr\u00e6k kan skrive til mediet. Her indstiller jeg ofte dirty_ratio til mellem 30 og 40 procent og dirty_background_ratio til mellem 10 og 20 procent. Databaser og sm\u00e5 random-I\/O-applikationer trives bedst med forudsigelig latenstid, derfor v\u00e6lger jeg 10\u201315 procent h\u00e5rdt og 3\u20135 procent bl\u00f8dt. For blandede web- og app-servere viser 15\u201320 procent h\u00e5rdt og 5\u201310 procent bl\u00f8dt sig at v\u00e6re et godt kompromis. Disse intervaller fungerer som udgangspunkt; derefter er det de faktiske m\u00e5linger fra dit system, der t\u00e6ller.<\/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>Filsystemaspekter og monteringsindstillinger<\/h2>\n<p>Writeback-stien ender i filsystemet \u2013 dets strategi er afg\u00f8rende for latenstider og sikkerhed. Ext4 med <em>data=ordnet<\/em> (Standard) skriver brugerdata f\u00f8r journal-commits; <em>data=tilbageskrivning<\/em> reducerer ventetiden, men medf\u00f8rer risiko for tab af gamle data efter systemnedbrud. Parameteren <code>commit=<\/code> (sekunder) bestemmer, hvor ofte journalen gemmes. Kortere intervaller mindsker risikoen for datatab, men kr\u00e6ver mere I\/O. XFS anvender et veludviklet log-design; store <em>logbst\u00f8rrelse<\/em> og en passende alignment fremmer genneml\u00f8bsopgaver. Btrfs samler skrivninger ved hj\u00e6lp af Copy-on-Write \u2013 det stabiliserer ventetiderne, men kan f\u00f8re til fragmentering ved sm\u00e5 tilf\u00e6ldige skrivninger og p\u00e5 SSD\u2019er med begr\u00e6nset kapacitet. Indstillinger som <em>nodatacow<\/em> kan hj\u00e6lpe med bestemte stier eller m\u00e5lrettet defragmentering, n\u00e5r der opst\u00e5r spidsbelastninger i latenstiden.<\/p>\n<p>Jeg bem\u00e6rker desuden <em>relatime<\/em>\/<em>Ingen tid<\/em> (reducerer antallet af metadataskrevninger), <em>dovenskab<\/em> (forsinket mtime\/atime er mere vedvarende) og journaliseringsbarrierer. Is\u00e6r p\u00e5 RAID-controllere eller i virtuelle maskiner er den korrekte cache-semantik afg\u00f8rende: Forkert indstillede skrivecacher \u00f8del\u00e6gger alt arbejde med \u00bbdirty tuning\u00ab.<\/p>\n\n<h2>Direct I\/O, O_SYNC og applikationsadf\u00e6rd<\/h2>\n<p>Ikke alle anvendelser passerer gennem sidecachen. Med <code>O_DIRECT<\/code> eller <code>O_SYNC<\/code>\/<code>O_DSYNC<\/code> Omg\u00e5 processer, der bruger dele af cachen eller kr\u00e6ver \u00f8jeblikkelig persistens. Databaser skriver typisk en WAL\/redo-log synkront og dataomr\u00e5der asynkront. Jeg kalibrerer \u00bbdirty-gr\u00e6nser\u00ab is\u00e6r for asynkrone stier, mens jeg garanterer lav latenstid for synkrone stier via hurtige journaler (NVMe, dedikerede LUN). N\u00e5r applikationer meget ofte <code>fsync()<\/code> N\u00e5r man kalder p\u00e5 dem, er store buffere ikke til megen nytte \u2013 latenstiden afh\u00e6nger i s\u00e5 fald i h\u00f8jere grad af controlleren, k\u00f8dybden og I\/O-scheduleren end af <em>dirty_ratio<\/em>.<\/p>\n\n<h2>Praktisk tuning trin for trin<\/h2>\n\n<p>F\u00f8r hver \u00e6ndring tjekker jeg <strong>faktiske v\u00e6rdier<\/strong> med <code>sysctl vm.dirty_ratio<\/code> og <code>sysctl vm.dirty_background_ratio<\/code>, for at dokumentere udgangssituationen. Ved kortvarige tests skriver jeg v\u00e6rdierne direkte ned efter <code>\/proc\/sys\/vm\/<\/code>, for eksempel <code>echo 15 &gt; \/proc\/sys\/vm\/dirty_ratio<\/code> og <code>echo 5 &gt; \/proc\/sys\/vm\/dirty_background_ratio<\/code>. Hvis tilpasningen er permanent, gemmer jeg den i <code>\/etc\/sysctl.conf<\/code> eller <code>\/etc\/sysctl.d\/*.conf<\/code>. \u00c6ndringer inds\u00e6tter jeg med <code>sysctl -p<\/code> med det samme, s\u00e5 jeg kan m\u00e5le effekten hurtigt. Den, der g\u00e5r mere i dybden med emnet systemregler, f\u00e5r gavn af praktiske r\u00e5d om <a href=\"https:\/\/webhosting.de\/da\/sysctl-optimering-af-webhostingserverens-ydeevne\/\">Sysctl-optimering<\/a> p\u00e5 produktive servere.<\/p>\n\n<h2>Udledning af v\u00e6rdier: Regneeksempler<\/h2>\n<p>Jeg starter gerne med konkrete tal. Eksempel 1: Web-\/app-server med 64 GB RAM, NVMe. M\u00e5let er lav latenstid. Jeg indstiller <code>dirty_background_bytes=1073741824<\/code> (1 GB) og <code>dirty_bytes=3221225472<\/code> (3 GB). Med en vedvarende NVMe-gennemstr\u00f8mning p\u00e5 2 GB\/s betyder det ca. 0,5\u20131,5 sekunder at t\u00f8mme \u2013 godt til interaktive belastninger. Eksempel 2: Backup-knude med 128 GB RAM, hurtigt SATA-RAID med 800 MB\/s. Jeg v\u00e6lger <code>dirty_background_ratio=10<\/code>, <code>dirty_ratio=35<\/code>. I absolutte tal er det ca. 12,8 GB og 44,8 GB; det tager 16\u201356 sekunder at t\u00f8mme RAID\u2019et. Det er fint nok, da opgaven ikke er interaktiv.<\/p>\n<p>Eksempel 3: Databaseserver med 256 GB RAM, separat journal p\u00e5 NVMe, data p\u00e5 SSD-array. Jeg s\u00e6tter en absolut gr\u00e6nse for at undg\u00e5 afvigelser: <code>dirty_background_bytes=2147483648<\/code> (2 GB), <code>dirty_bytes=8589934592<\/code> (8 GB). Det g\u00f8r det muligt at planl\u00e6gge st\u00f8rrelsen p\u00e5 crash-vinduet og mindsker pludselige afbrydelser ved checkpoints.<\/p>\n\n<h2>Writeback-timing og relaterede parametre<\/h2>\n\n<p>Ud over gr\u00e6nsev\u00e6rdierne har f\u00f8lgende faktorer indflydelse <strong>Timer<\/strong> Writeback-adf\u00e6rden og dermed brugeroplevelsen i applikationerne. Med <code>vm.dirty_writeback_centisekunder<\/code> styrer jeg det interval, hvori kernel-flusheren v\u00e6kkes, mens <code>vm.dirty_expire_centisecs<\/code> definerer, hvor gamle \u00bbdirty pages\u00ab h\u00f8jst m\u00e5 blive. Kortere intervaller medf\u00f8rer hyppigere, men mindre flushes, mens l\u00e6ngere intervaller sparer I\/O-kald, men risikerer st\u00f8rre bundter. Jeg justerer kun disse v\u00e6rdier, hvis m\u00e5linger viser reelle ulemper, f.eks. for sj\u00e6ldne flushes p\u00e5 hurtige NVMe-drev. Hvis man g\u00e5r metodisk til v\u00e6rks her, undg\u00e5r man svingninger mellem for ivrig og for tr\u00e6g writeback-aktivitet.<\/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>Overv\u00e5gning og finjustering<\/h2>\n\n<p>Efter justeringerne bem\u00e6rker jeg <strong>kontinuerlig<\/strong> n\u00f8gletallene, der g\u00f8r det muligt at synligg\u00f8re succeser og bivirkninger. I <code>\/proc\/meminfo<\/code> Jeg tjekker \u201eDirty\u201c og \u201eWriteback\u201c for at se bufferbeholdninger og aktive flushes. V\u00e6rkt\u00f8jer som iostat, sar eller atop viser mig gennemstr\u00f8mning, k\u00f8er og tendenser i latenstiden. Dette indl\u00e6g om giver en god introduktion til m\u00e5linger <a href=\"https:\/\/webhosting.de\/da\/server-io-wait-analyse-iostat-vmstat-metrics-disk\/\">Analyse af I\/O-ventetid<\/a>. F\u00f8rst p\u00e5 baggrund af disse data justerer jeg gr\u00e6nserne op eller ned i sm\u00e5 trin, s\u00e5 der ikke opst\u00e5r uventede bivirkninger.<\/p>\n\n<h2>Containere, cgroups og retf\u00e6rdig fordeling<\/h2>\n<p>I container-milj\u00f8er deler arbejdsbelastninger de samme kerne-mekanismer. Cgroup-Writeback sikrer, at \u00bbdirty pages\u00ab tilskrives den p\u00e5g\u00e6ldende for\u00e5rsager. Jeg bruger cgroups\u2019 I\/O-controllere (blkcg) til at begr\u00e6nse b\u00e5ndbredde eller IOPS pr. container, hvis enkelte lejere bufferer for aggressivt. Absolutte byte-gr\u00e6nser p\u00e5 v\u00e6rtsniveau (<em>beskidte_bytes<\/em>) forhindrer, at en enkelt g\u00e6st sluger hele Dirty-budgettet. Derudover begr\u00e6nser jeg lagerpladsen via <code>hukommelse.max<\/code>, s\u00e5 Writeback ikke f\u00f8rst reagerer ved global belastning. M\u00e5let er stadig: Ingen g\u00e6stebelastning m\u00e5 medf\u00f8re host-d\u00e6kkende begr\u00e6nsninger af <em>dirty_ratio<\/em> tvinge.<\/p>\n\n<h2>Hostingmilj\u00f8er og virtuelle maskiner<\/h2>\n\n<p>I flerklientops\u00e6tninger og virtuelle maskiner er jeg opm\u00e6rksom p\u00e5 <strong>Overbooking<\/strong> for RAM og I\/O, fordi procentvise gr\u00e6nser har en anden virkning p\u00e5 disse omr\u00e5der. Absolutte gr\u00e6nser i byte kan forhindre, at enkelte g\u00e6ster opbygger for meget buffer og bremser naboerne. Jeg tager h\u00f8jde for lagringsdeduplikering, ballooning og controller-caches, fordi de overlejrer buffereffekter. For managed-servere betaler det sig, hvis udbyderen indstiller fornuftige standardv\u00e6rdier, s\u00e5 kunderne oplever konstante responstider. Dem, der driver egne noder, har fordel af klart definerede profilindstillinger for hver workload-klasse.<\/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>Almindelige misforst\u00e5elser og forhindringer<\/h2>\n<ul>\n  <li><strong>\u201eSt\u00f8rre buffer = stadig st\u00f8rre gennemstr\u00f8mning.\u201c<\/strong> Dette g\u00e6lder ikke for arbejdsbelastninger med mange tilf\u00e6ldige data eller enheder med lav k\u00f8dybde. For store buffere skaber flush-bursts og k\u00f8er.<\/li>\n  <li><strong>\u201edirty_ratio har ingen indflydelse p\u00e5 Reads.\u201c<\/strong> Indirekte set ja: Aggressive writeback-faser fortr\u00e6nger cachesider og \u00f8ger l\u00e6selatenserne.<\/li>\n  <li><strong>\u201eBytes og fornuft g\u00e5r op i en h\u00f8jere enhed.\u201c<\/strong> Nej. Hvis du angiver Bytes-varianter, oph\u00e6ver de de tilsvarende Ratio-v\u00e6rdier. V\u00e6r entydig.<\/li>\n  <li><strong>\u201efsync() g\u00f8r Dirty-Limits irrelevante.\u201c<\/strong> Nej. Hyppige synkroniseringer mindsker ganske vist risikovinduet, men den resterende belastning er stadig underlagt gr\u00e6nsev\u00e6rdierne.<\/li>\n  <li><strong>\u201eEt hurtigt lagringsmedie l\u00f8ser alt.\u201c<\/strong> Ikke hvis Block-Layer begr\u00e6nser hastigheden (WBT), eller hvis filsystemet er monteret p\u00e5 en suboptimal m\u00e5de.<\/li>\n  <li><strong>\u201eDrop_caches er et optimeringsv\u00e6rkt\u00f8j.\u201c<\/strong> T\u00f8mning af cachen forvr\u00e6nger m\u00e5lingerne og forv\u00e6rrer spidsbelastninger i latenstiden. I produktionsmilj\u00f8et undg\u00e5r jeg det.<\/li>\n<\/ul>\n\n<h2>Fejlfinding: typiske symptomer og l\u00f8sninger<\/h2>\n\n<p>Pile op <strong>Toppen af ventetiden<\/strong>, s\u00e6tter jeg f\u00f8rst t\u00e6rskelv\u00e6rdien for baggrundsaktivitet lavere, s\u00e5 flush-processerne starter tidligere, og der opst\u00e5r f\u00e6rre store skriveb\u00f8lger. Hvis applikationer periodevis blokerer, er den faste gr\u00e6nse som regel sat for h\u00f8jt, eller ogs\u00e5 kan mediet ikke h\u00e5ndtere de opst\u00e5ede flush-bursts. I s\u00e5danne tilf\u00e6lde s\u00e6nker jeg dirty_ratio, tjekker readahead-indstillingerne og ser p\u00e5 filsystemets journaliseringsindstillinger. Ved meget hurtig NVMe-hardware h\u00e6ver jeg gradvist baggrundst\u00e6rsklen for ikke at begr\u00e6nse genneml\u00f8bshastigheden kunstigt. Efter hver \u00e6ndring f\u00f8lger jeg m\u00e5leresultaterne, ikke min mavefornemmelse.<\/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>Kort oversigt til praksis<\/h2>\n\n<p>Med blot nogle f\u00e5 <strong>Justeringsskruer<\/strong> Jeg kan p\u00e5virke, hvordan Linux bufferer skrivedata, hvorn\u00e5r flusherne starter, og hvorn\u00e5r kernen bremser. Dirty Background Ratio s\u00f8rger for en rolig oprydning, mens Dirty Ratio begr\u00e6nser RAM-forbruget mere strengt. Forholdet mellem disse to v\u00e6rdier afg\u00f8r, om dit system sigter mod j\u00e6vne latenstider eller maksimal gennemstr\u00f8mning. Jeg dokumenterer standardindstillingerne, foretager \u00e6ndringer i sm\u00e5 skridt og analyserer m\u00e5lingerne konsekvent. S\u00e5ledes opst\u00e5r der en konfiguration, der skaber en fornuftig balance mellem arbejdsbyrde, medium og risiko og i praksis virker m\u00e6rkbart hurtigere.<\/p>","protected":false},"excerpt":{"rendered":"<p>Find ud af, hvordan du med \u00bblinux dirty ratio\u00ab og \u00bbdirty background ratio\u00ab m\u00e5lrettet kan optimere din servers skriveydelse og kerneydelse samt administrere \u00bbdirty pages\u00ab effektivt.<\/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":"144","_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\/da\/wp-json\/wp\/v2\/posts\/20858","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=20858"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20858\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/20851"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=20858"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=20858"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=20858"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}