{"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-kernel-cache","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/writeback-cache-linux-kernel-cache\/","title":{"rendered":"S\u00e5dan forst\u00e5r du writeback-cache og dirty pages i Linux-kernen"},"content":{"rendered":"<p>Writeback-cachen i Linux-kernen styrer, hvorn\u00e5r \u00e6ndrede data gemmes som <strong>Beskidte sider<\/strong> forbliver i RAM, og hvorn\u00e5r kernen skriver dem samlet til lagringsmediet. Jeg forklarer, hvordan denne proces <strong>Ydelse<\/strong>, forsinkelser og datasikkerhed, og hvilke indstillinger der virkelig betyder noget i hverdagen.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<ul>\n  <li><strong>Beskidte sider<\/strong> markerer \u00e6ndrede sider i RAM, som endnu ikke er gemt p\u00e5 datamediet.<\/li>\n  <li><strong>Writeback<\/strong> samler \u00e6ndringerne og skriver dem effektivt i st\u00f8rre blokke.<\/li>\n  <li><strong>T\u00e6rskelv\u00e6rdier<\/strong> Ligesom vm.dirty_ratio styrer hastigheden og begr\u00e6nsningen.<\/li>\n  <li><strong>Synkronisering<\/strong> Brug af fsync\/Flush forhindrer datatab.<\/li>\n  <li><strong>Overv\u00e5gning<\/strong> Via \/proc og v\u00e6rkt\u00f8jer vises belastning og forsinkelser.<\/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>S\u00e5dan fungerer sidecachen<\/h2>\n\n<p>Jeg l\u00e6ser en fil, kernen placerer dataene i sidecachen, og senere adgang sker fra <strong>Hukommelse<\/strong> i stedet for fra pladen. Under skrivningen markerer systemet de \u00e6ndrede sider som <strong>Beskidt<\/strong> og bekr\u00e6fter ofte anmodningen med det samme, s\u00e5 applikationen kan forts\u00e6tte. Denne adskillelse reducerer ventetiderne, fordi langsomme I\/O-adgange ikke bremser hver enkelt app direkte. Cachen holder desuden ofte anvendte blokke klar og \u00f8ger hitraten ved gentagne adgange. Hvis du vil dykke dybere ned i emnet, kan du finde baggrundsinformation i min oversigt over <a href=\"https:\/\/webhosting.de\/da\/filsystem-caching-linux-side-cache-cacheboost\/\">Caching af filsystemet<\/a>, der viser, hvilken rolle l\u00e6se- og skrivestier spiller i hverdagen.<\/p>\n\n<h2>Dirty Pages: Betydning og konsekvenser<\/h2>\n\n<p>\u00bbDirty Pages\u00ab er \u00e6ndrede hukommelsessider, der endnu ikke er gemt permanent og derfor kun findes i <strong>RAM<\/strong> findes. S\u00e5 l\u00e6nge de er beskidte, har jeg en vis <strong>Risiko<\/strong>: Et str\u00f8msvigt kan annullere disse \u00e6ndringer. Alligevel opn\u00e5r jeg en h\u00f8jere skrivehastighed p\u00e5 denne m\u00e5de, fordi kernen samler mange sm\u00e5 opdateringer. Hvis andelen af beskidte sider stiger, \u00f8ges presset p\u00e5 de enheder, der skriver data tilbage. I s\u00e5 fald kan systemet frig\u00f8re hukommelse ved at skrive de p\u00e5g\u00e6ldende sider til drevet med h\u00f8j prioritet.<\/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: Udl\u00f8ser og forl\u00f8b<\/h2>\n\n<p>Writeback udf\u00f8res tidsstyret, h\u00e6ndelsesstyret og p\u00e5 foresp\u00f8rgsel <strong>Apps<\/strong>. Kernen samler \u00bbdirty pages\u00ab, danner passende I\/O-sekvenser og sender dem via bloklaget til <strong>Lagringsenhed<\/strong>. Undervejs griber filsystemer, reclaimere og I\/O-schedulere ind for at styre r\u00e6kkef\u00f8lgen og st\u00f8rrelsen. Synkroniseringskald som fsync sikrer, at bestemte data gemmes sikkert p\u00e5 mediet, f\u00f8r processen forts\u00e6tter. I perioder med h\u00f8j aktivitet ser jeg i statistikkerne en stigende andel af writeback, som falder igen efter flush.<\/p>\n\n<h2>Interne mekanismer: balance_dirty_pages, BDI og Writeback-Worker<\/h2>\n\n<p>Under motorhjelmen arbejder flere komponenter sammen. Skrivende tr\u00e5de genneml\u00f8ber <strong>balance_dirty_pages()<\/strong>, som tager h\u00f8jde for den aktuelle \u00bbDirty-Last\u00ab, enhedens hastighed og de indstillede gr\u00e6nser. Det regulerer processernes skrivehastighed (throttling), s\u00e5 skrivningen i baggrunden kan f\u00f8lge med. Hver <strong>Backing-enhed<\/strong>-Kontekst (bdi) \u2013 typisk en blokenhed eller et filsystem-backend \u2013 har sine egne arbejdsk\u00f8er med <strong>Flusher-tr\u00e5de<\/strong>, som omdanner de s\u00e5kaldte \u00bbDirty Pages\u00ab til velordnede I\/O-anmodninger. Denne fordeling forhindrer, at en langsom enhed bremser alle de andre, og forbedrer retf\u00e6rdigheden mellem arbejdsbelastningerne.<\/p>\n\n<p>Begr\u00e6nsningen er adaptiv: N\u00e5r jeg observerer hurtigere skrivere eller st\u00f8rre sammenh\u00e6ngende omr\u00e5der, stiger de tilladte m\u00e6ngder af \u00bbdirty\u00ab data kortvarigt. Ved flaskehalse, h\u00f8je ventetider eller m\u00e6ttede k\u00f8er tr\u00e6kker kernen mere aggressivt i h\u00e5ndbremsen og tvinger skrivere til at holde pause, indtil bufferen igen har luft. Netop dette samspil forklarer, hvorfor sm\u00e5 parameter\u00e6ndringer kan f\u00f8re til m\u00e6rkbart forskellige ventetidsprofiler.<\/p>\n\n<h2>T\u00e6rskelv\u00e6rdier: vm.dirty_background_ratio og vm.dirty_ratio<\/h2>\n\n<p>Jeg styrer adf\u00e6rden ved hj\u00e6lp af to vigtige gr\u00e6nser, der fastl\u00e6gger andelen af forurenede sider i forhold til <strong>RAM<\/strong> definere. Hvis jeg overskrider baggrundsv\u00e6rdien, begynder kernen i <strong>Baggrund<\/strong> at skrive. Hvis jeg n\u00e5r den strenge gr\u00e6nsev\u00e6rdi, begr\u00e6nser systemet de skrivende processer, indtil der er skyllet nok data tilbage. P\u00e5 den m\u00e5de forbliver lageret brugbart, selvom enkelte programmer genererer store m\u00e6ngder \u00e6ndringer. Hvis man arbejder med byte-baserede gr\u00e6nser, indstiller man de tilsvarende *_bytes-parametre i stedet for ratio-v\u00e6rdierne.<\/p>\n\n<h2>Tabel: Relevante kerneparametre og n\u00f8gletal<\/h2>\n\n<p>Jeg bruger nogle f\u00e5 centrale kontakter til m\u00e5lrettet at styre og synligg\u00f8re writeback, latenstid og gennemstr\u00f8mning; nedenst\u00e5ende oversigt hj\u00e6lper med at <strong>Klassificering<\/strong> og hurtige <strong>Unders\u00f8gelse<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parameter\/n\u00f8gletal<\/th>\n      <th>Effekt<\/th>\n      <th>Startv\u00e6rdier\/Bem\u00e6rkning<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>vm.dirty_background_ratio \/ vm.dirty_background_bytes<\/td>\n      <td>Start baggrunds-writeback, n\u00e5r andelen af beskadigede sider overstiger denne t\u00e6rskelv\u00e6rdi.<\/td>\n      <td>V\u00e6lg en ret konservativ indstilling for serveren, s\u00e5 flush starter tidligere.<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_ratio \/ vm.dirty_bytes<\/td>\n      <td>\u00d8vre gr\u00e6nse for \u00bbDirty Pages\u00ab; herfra begr\u00e6nses skriverne.<\/td>\n      <td>For h\u00f8j \u00f8ger risikoen for forsinkelser, for lav g\u00e5r det ud over gennemstr\u00f8mningen.<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_writeback_centisekunder<\/td>\n      <td>Interval, hvor kernen kontrollerer, om der er \u00bbdirty pages\u00ab til baggrundsflushing.<\/td>\n      <td>Mindre intervaller udj\u00e6vner belastningstoppe, men medf\u00f8rer flere opv\u00e5gninger.<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_expire_centisecs<\/td>\n      <td>Den alder, hvorfra \u201eDirty Pages\u201c betragtes som \u00bbmodne\u00ab og foretr\u00e6kkes som emne for skrivning.<\/td>\n      <td>H\u00f8jere v\u00e6rdier giver st\u00f8rre samling, men mindsker konsistensgarantierne i tilf\u00e6lde af fejl.<\/td>\n    <\/tr>\n    <tr>\n      <td>\/proc\/meminfo: Dirty, Writeback<\/td>\n      <td>Aktuelt antal forurenede eller aktivt tilbagef\u00f8rte sider.<\/td>\n      <td>Nyttigt til live-overv\u00e5gning under belastningstests.<\/td>\n    <\/tr>\n    <tr>\n      <td>Monterings-\/FS-indstillinger (f.eks. barrierer, journal-tilstand)<\/td>\n      <td>P\u00e5virker r\u00e6kkef\u00f8lgen, varigheden og omkostningerne ved de enkelte flushes.<\/td>\n      <td>V\u00e6lg det rette afh\u00e6ngigt af filsystemet og enheden.<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Jeg afl\u00e6ser disse v\u00e6rdier regelm\u00e6ssigt og sammenholder dem med I\/O-ventetider i Top, iostat eller lignende <strong>V\u00e6rkt\u00f8jer<\/strong>. Det giver et klart billede af, om Writeback selv s\u00e6tter en begr\u00e6nsning, eller om det <strong>Opbevaring<\/strong> er p\u00e5 gr\u00e6nsen.<\/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>Overv\u00e5gning og diagnose: Hvad jeg m\u00e5ler<\/h2>\n\n<p>Jeg tjekker f\u00f8rst \/proc\/meminfo og holder \u00f8je med felterne \u00bbDirty\u00ab og \u00bbWriteback\u00ab, mens jeg m\u00e5lrettet <strong>Belastning<\/strong> skaber. Hvis \u00bbDirty\u00ab stiger kraftigt og forbliver h\u00f8jt, mangler der ofte rettidige flushes eller det <strong>Medium<\/strong> er fuldt udnyttet. Hvis Writeback stiger, men Dirty kun falder langsomt, bremser m\u00e5lenheden eller I\/O-stien. Hvis latenstidstoppe falder sammen med Writeback-toppe, udj\u00e6vner jeg intervallet eller s\u00e6nker forholdsv\u00e6rdierne. For at f\u00e5 et indblik i typiske m\u00f8nstre hj\u00e6lper en kort <a href=\"https:\/\/webhosting.de\/da\/ydelsesforbedring-af-linux-sidecachen\/\">Page-Cache-Booster<\/a>, der opsummerer de praktiske justeringsskruer og m\u00e5lepunkter.<\/p>\n\n<h2>Udvidede m\u00e5lepunkter, vmstat og sporing<\/h2>\n\n<p>Ud over \/proc\/meminfo bruger jeg meget detaljerede t\u00e6llere for at skelne mellem \u00e5rsag og virkning. I <strong>\/proc\/vmstat<\/strong> Felter som nr_dirty, nr_writeback, nr_dirtied og nr_written giver en indikation af dynamikken: Hvor hurtigt bliver dataene \u00bbbeskidte\u00ab, og hvor hurtigt bliver de \u00bbrenset\u00ab? Derudover overv\u00e5ger jeg l\u00e6ngden af I\/O-k\u00f8erne og afbrydelsesprocenten for sammenfletningsoperationer i bloklaget.<\/p>\n\n<ul>\n  <li>vmstat 1: viser pr. sekund afvigelse i dirty\/writeback og IO-ventetid (wa),<\/li>\n  <li>\/proc\/pressure\/memory: viser hukommelsesbelastningen, som indirekte udl\u00f8ser writeback,<\/li>\n  <li>Tracepoints (writeback:*) og blokbegivenheder: afsl\u00f8rer r\u00e6kkef\u00f8lgen og st\u00f8rrelsen af flush-operationerne,<\/li>\n  <li>perf\/ftrace: identificerer hotspots i balance_dirty_pages og Flusher-arbejdsk\u00f8er.<\/li>\n<\/ul>\n\n<p>Hvis jeg ser, at nr_dirtied konstant ligger h\u00f8jere end nr_written, er det et klart tegn p\u00e5 forest\u00e5ende begr\u00e6nsningspres eller for sene baggrunds-flushes. Hvis spidsv\u00e6rdier i writeback-tracepoints stemmer overens med latenstidsspidser, optimerer jeg intervallet og batchst\u00f8rrelserne.<\/p>\n\n<h2>HDD vs. SSD: Indvirkning p\u00e5 writeback-designet<\/h2>\n\n<p>P\u00e5 roterende plader giver st\u00f8rre, sammenh\u00e6ngende flushes s\u00e6rligt meget, fordi de sparer tid p\u00e5 den dyre s\u00f8gning <strong>Undg\u00e5 at<\/strong>. SSD\u2019er drager ogs\u00e5 fordel heraf, men her er det fordelingen af skrivningerne og samspillet med <strong>Controller<\/strong>. Jeg undg\u00e5r for mange sm\u00e5 synkroniseringer, s\u00e5 firmwaren kan fungere effektivt. Samtidig l\u00e6gger jeg i forbindelse med SSD'er st\u00f8rre v\u00e6gt p\u00e5 konsistensbarrierer og flush-semantik for virkelig at udnytte enhedens garantier. Blandede arbejdsbelastninger med tilf\u00e6ldige l\u00e6sninger og skrivninger reagerer m\u00e6rkbart p\u00e5 sm\u00e5 justeringer af dirty-t\u00e6rsklerne og flush-timingen.<\/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>Enhedscache, flush-semantik og beskyttelse mod str\u00f8msvigt (PLP)<\/h2>\n\n<p>Om en flush virkelig vedbliver, afh\u00e6nger ogs\u00e5 af <strong>Enhedscache<\/strong> fra. Mange drev gemmer data i deres eget DRAM. Uden <strong>Beskyttelse mod str\u00f8mtab (PLP)<\/strong> risikerer jeg datatab, hvis cachen ikke t\u00f8mmes i tide. Writeback drager ganske vist fordel af enhedens cache, men jeg sikrer mig, at barrierer og flush-kommandoer overholdes. P\u00e5 systemer med RAID-controllere vurderer jeg, om der findes en batteri- eller flash-baseret cache; i s\u00e5 fald er synkroniserede skrivninger ofte en fordel uden at g\u00e5 p\u00e5 kompromis med sikkerheden.<\/p>\n\n<p>Jeg skelner desuden mellem: FUA (Force Unit Access) tvinger persistens pr. I\/O, men koster IOPS. Flush-barrierer kan sikre flere skrivninger p\u00e5 \u00e9n gang. For s\u00e6rligt kritiske stier (f.eks. journaler) accepterer jeg FUA\/flush-overhead, mens jeg lader bulkdata forblive i writeback-str\u00f8mmen. Hvis man \u00e6ndrer mount-indstillinger eller controller-indstillinger, skal man efterf\u00f8lgende verificere ved hj\u00e6lp af belastningstests, at den tilsigtede flush-semantik fungerer.<\/p>\n\n<h2>Datakonsistens: Korrekt brug af fsync, Flush og FUA<\/h2>\n\n<p>Jeg bruger fsync specifikt til data med h\u00f8j <strong>V\u00e6rdi<\/strong>, der har brug for en klar holdbarhedsgaranti. Kernen kan udf\u00f8re flush-operationer helt frem til lagringsmediet og med FUA sikre, at en skrivning virkelig <strong>forts\u00e6tter<\/strong>, inden bekr\u00e6ftelsen kommer tilbage. Denne fremgangsm\u00e5de koster tid og IOPS, men forhindrer datatab i tilf\u00e6lde af nedbrud. Uden s\u00e5danne barrierer melder systemet transaktionerne som gennemf\u00f8rte, selvom bytes stadig befinder sig i SSD\u2019ens cache eller i RAM\u2019en. Jeg tilpasser disse beslutninger til applikationen: Transaktionslogfiler sikkerhedskopieres h\u00e5rdt, mens bulk-opdateringer sikkerhedskopieres bl\u00f8dt.<\/p>\n\n<h2>Eksempler p\u00e5 optimering af hosting- og database-arbejdsbelastninger<\/h2>\n\n<p>Til web- og databaseservere indstiller jeg ofte en moderat v\u00e6rdi for `dirty_background_ratio` og holder `dirty_ratio` betydeligt h\u00f8jere for at sikre, at baggrundsflush udf\u00f8res i tide <strong>Start<\/strong>, uden at Schreiber for tidligt <strong>Bremse<\/strong>. Ved skrivebursts s\u00e6nker jeg writeback-intervallet, s\u00e5 writeback-mekanismerne aktiveres tidligere. P\u00e5 systemer med meget RAM foretr\u00e6kker jeg *_bytes-v\u00e6rdier, s\u00e5 de reelle st\u00f8rrelser kommer til udtryk i stedet for procenter. Jeg tester hver \u00e6ndring med gentagelige benchmarks og m\u00e5ler latenstid, gennemstr\u00f8mning og 95-\/99-percentiler. Denne praktiske oversigt giver mig en kortfattet vejledning i, hvordan sidecachen virker: <a href=\"https:\/\/webhosting.de\/da\/ydelsesforbedring-af-linux-sidecachen\/\">Linux-sidecache-ydeevneforbedrer<\/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 og mmap: N\u00e5r sidecachen omg\u00e5s<\/h2>\n\n<p>Ikke alle applikationer bruger sidecachen p\u00e5 samme m\u00e5de. Med <strong>O_DIRECT<\/strong> kan den bevidst omg\u00e5 cachen og skrive eller l\u00e6se direkte til enheden. Det aflaster RAM\u2019en og forkorter overf\u00f8rselsvejene, men jeg g\u00e5r dermed glip af fordelene ved batching og readahead. Ved store, engangsoverf\u00f8rsler kan det v\u00e6re fornuftigt; ved mange sm\u00e5 skrivninger g\u00e5r jeg derimod glip af fordelene ved writeback.<\/p>\n\n<p>Med <strong>mmap<\/strong> og med Copy-on-Write markerer jeg sider som \u00bbdirty\u00ab, n\u00e5r de \u00e6ndres; flush'et foreg\u00e5r via den normale writeback-sti eller ved hj\u00e6lp af <strong>msync<\/strong>. Jeg tager h\u00f8jde for dette, n\u00e5r applikationer i h\u00f8j grad benytter memory-mapped I\/O: Der kan opst\u00e5 uventede spidsbelastninger, selvom appen \u201ekun\u201c skriver til hukommelsen. Ogs\u00e5 her er det nyttigt at fasts\u00e6tte gr\u00e6nser for forholdet mellem ratio og bytes for at styre tidspunktet for overskrivningen.<\/p>\n\n<h2>Containermilj\u00f8er og cgroup-writeback<\/h2>\n\n<p>I multi-tenant-ops\u00e6tninger forhindrer jeg \u201est\u00f8jende naboer\u201c ved hj\u00e6lp af <strong>cgroups<\/strong>. Kernen tildeler \u00bbdirty pages\u00ab til den gruppe, der har for\u00e5rsaget dem (cgroup-Writeback), s\u00e5 baggrundsflush og begr\u00e6nsning fordeles mere retf\u00e6rdigt. Med hukommelsesgr\u00e6nser (<strong>hukommelse.h\u00f8j<\/strong>, memory.max) begr\u00e6nser jeg antallet af \u00bbdirty-spidser\u00ab pr. container. Derudover indstiller jeg I\/O-kvoter via I\/O-controlleren for at forhindre, at enkelte arbejdsbelastninger fylder hele enhedsk\u00f8en.<\/p>\n\n<p>I praksis fasts\u00e6tter jeg realistiske \u00f8vre gr\u00e6nser for hver serviceklasse: Batch-jobs med stor skrivebelastning f\u00e5r store \u00bbdirty budgets\u00ab, mens frontends, hvor latenstiden er afg\u00f8rende, f\u00e5r strammere. P\u00e5 den m\u00e5de forbliver den samlede latenstid mere stabil, fordi Writeback ikke pludseligt begr\u00e6nser hastigheden for alle, s\u00e5 snart en enkelt container kommer ud af trit.<\/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>Netv\u00e6rksfilsystemer (NFS, SMB, distribuerede filsystemer)<\/h2>\n\n<p>I netv\u00e6rksfilsystemer kommer der endnu et bufferniveau til. Lokale \u00bbdirty pages\u00ab signalerer blot, at data er undervejs; om de <strong>fjernbetjent<\/strong> Det er protokollen (commit-semantik) og serveren, der afg\u00f8r, om dataene skal gemmes. Jeg stoler ikke p\u00e5 implicitte flushes: Kritiske data synkroniserer jeg eksplicit. Samtidig tager jeg h\u00f8jde for round-trip-omkostningerne \u2013 for hyppige synkroniseringer over netv\u00e6rket forv\u00e6rrer latenstiderne m\u00e6rkbart.<\/p>\n\n<p>I blandede arbejdsbelastninger adskiller jeg stierne: Lokale, midlertidige filer udnytter sidecachen maksimalt; netv\u00e6rksmonteringer f\u00e5r strengere synkroniseringspunkter. P\u00e5 den m\u00e5de forhindrer jeg, at writeback via netv\u00e6rket bliver en flaskehals, mens lokale opgaver stadig har ressourcer til r\u00e5dighed.<\/p>\n\n<h2>I\/O-scheduler, blk-mq og k\u00f8dybde<\/h2>\n\n<p>Hvor effektivt writeback-batches ender p\u00e5 enheden, afh\u00e6nger ogs\u00e5 af <strong>Blocklayer<\/strong> fra. Med <strong>blk-mq<\/strong> I\/O'er fordeles p\u00e5 flere k\u00f8er; schedulere som mq-deadline eller kyber prioriterer og ordner dem. Jeg v\u00e6lger scheduleren alt efter mediet: P\u00e5 NVMe er \u201enone\u201c ofte en god l\u00f8sning, mens Deadline hj\u00e6lper med at ordne skrivninger p\u00e5 SATA eller SAS.<\/p>\n\n<p>Die <strong>K\u00f8ens dybde<\/strong> Jeg indstiller det s\u00e5ledes, at enheden udnyttes fuldt ud, men ikke overbelastes. For lav dybde g\u00e5r der gennemstr\u00f8mning tabt, for dyb dybde \u00f8ger spredningen i latenstiden og g\u00f8r begr\u00e6nsningen besv\u00e6rlig. Writeback drager fordel af moderate dybder og store, sammenh\u00e6ngende anmodninger. Jeg overv\u00e5ger sammenl\u00e6gningsrater og \u201einflight\u201c-t\u00e6llere; faldende sammenl\u00e6gningsrater tyder p\u00e5 for sm\u00e5 batches eller konkurrerende tilf\u00e6ldige arbejdsbelastninger.<\/p>\n\n<h2>Reproducerbare tests og sikker tilbagef\u00f8rsel<\/h2>\n\n<p>Inden jeg justerer regulatorerne, registrerer jeg den aktuelle tilstand og tester <strong>Reproducerbar<\/strong> og planlagte tilbagespring. Jeg bruger identiske arbejdsbelastninger og identiske datam\u00e6ngder og varmer cachen m\u00e5lrettet op eller t\u00f8mmer den bevidst for at sikre sammenlignelige testk\u00f8rsler. Indstillings\u00e6ndringer foretager jeg f\u00f8rst midlertidigt, overv\u00e5ger m\u00e5lingerne og gemmer dem f\u00f8rst derefter permanent.<\/p>\n\n<pre><code># Eksempel: midlertidige optimeringsindstillinger (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# Kort belastningstest (eksempel, afh\u00e6ngig af arbejdsbelastningen)\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>I mellemtiden l\u00e6ser jeg \/proc\/meminfo, vmstat og iostat sidel\u00f8bende og sammenholder spidsbelastningerne. Efter testen nulstiller jeg v\u00e6rdierne eller overf\u00f8rer dem p\u00e5 en kontrolleret m\u00e5de til systemkonfigurationen. I den forbindelse dokumenterer jeg <strong>dato<\/strong>, <strong>Kernen<\/strong>-version, enheder og filsystemoplysninger, s\u00e5 senere sammenligninger forbliver p\u00e5lidelige.<\/p>\n\n<h2>Almindelige problemer og l\u00f8sninger<\/h2>\n\n<p>Hvis systemet ser ud til at k\u00f8re flydende, men skriveoperationer g\u00e5r i st\u00e5, tjekker jeg, om der er tale om begr\u00e6nsning p\u00e5 grund af en for lav <strong>dirty_ratio<\/strong>. Hvis Dirty forbliver p\u00e5 et h\u00f8jt niveau, mangler der b\u00e5ndbredde, eller det <strong>Interval<\/strong> til flush er for lang. Hvis latenstiderne eksploderer ved korte synkroniseringsstorme, fordeler jeg belastningen p\u00e5 mindre batches og s\u00f8rger for bedre I\/O-planl\u00e6gning. Hvis cachen n\u00e6sten ikke kommer i gang, kan en for lille *_bytes-gr\u00e6nse m\u00e5ske forhindre en fornuftig batching. Et n\u00e6rmere kig p\u00e5 <a href=\"https:\/\/webhosting.de\/da\/server-page-cache-eviction-linux-memory-print-optimisation-insight\/\">Cache-udskiftning ved udskrivning<\/a> hj\u00e6lper, n\u00e5r der oven i k\u00f8bet opst\u00e5r pladsmangel.<\/p>\n\n<h2>Gode praksis og kort tjekliste<\/h2>\n\n<p>Jeg skelner strengt mellem data, der skal gemmes med det samme, og data, der m\u00e5 gemmes med en vis forsinkelse, for at <strong>Str\u00f8m<\/strong> at vinde. For logfiler og transaktionsjournaler tvinger jeg synkroniseringer igennem; for midlertidige artefakter lader jeg writeback k\u00f8re frit og holder kun \u00f8je med begr\u00e6nsningsgr\u00e6nsen. F\u00f8r hver justering m\u00e5ler jeg den aktuelle tilstand og sammenligner A\/B via definerede scenarier. Jeg holder antallet af samtidige skrivere i skak, fordi ukoordinerede str\u00f8mme mindsker fordelene ved batching. Og jeg dokumenterer \u00e6ndringer med det samme, s\u00e5 fremtidige analyser kan baseres p\u00e5 klare <strong>Data<\/strong> baseret.<\/p>\n\n<h2>Praktisk oversigt for hurtige resultater<\/h2>\n\n<p>Writeback-cachen samler \u00e6ndringer i <strong>Side<\/strong> Cache reducerer I\/O-omkostningerne og aflaster applikationerne. \u00bbDirty Pages\u00ab er ikke en fejl, men et m\u00e5lrettet middel til at \u00f8ge hastigheden, s\u00e5 l\u00e6nge jeg kender gr\u00e6nserne og konsistenskravene. Med parametrene vm.dirty_background_ratio og vm.dirty_ratio styrer jeg, hvorn\u00e5r kernen arbejder stille i baggrunden, og hvorn\u00e5r den bremser skriveoperationer. V\u00e6rkt\u00f8jer og \/proc giver mig det n\u00f8dvendige overblik over dirty og writeback, s\u00e5 jeg ikke famler i blinde. N\u00e5r jeg mestrer disse indstillinger, k\u00f8rer web, databaser og batch-jobs m\u00e6rkbart hurtigere uden at <strong>Integritet<\/strong> at bringe mine data i fare.<\/p>","protected":false},"excerpt":{"rendered":"<p>Writeback-cache i Linux-kernen: Dirty Pages, sidecache og tilbageskrivning forklaret p\u00e5 en forst\u00e5elig m\u00e5de.<\/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":"138","_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\/da\/wp-json\/wp\/v2\/posts\/20548","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=20548"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20548\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/20541"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=20548"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=20548"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=20548"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}