{"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-kaernans-cache","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/writeback-cache-linux-kernel-cache\/","title":{"rendered":"Att f\u00f6rst\u00e5 writeback-cache och smutsiga sidor i Linux-k\u00e4rnan"},"content":{"rendered":"<p>Writeback-cachen i Linux-k\u00e4rnan styr n\u00e4r \u00e4ndrade data ska <strong>Smutsiga sidor<\/strong> f\u00f6rblir i RAM-minnet och n\u00e4r k\u00e4rnan skriver dem samlade till lagringsmediet. Jag f\u00f6rklarar hur denna process <strong>Prestanda<\/strong>, hur det p\u00e5verkar latens och datas\u00e4kerhet och vilka inst\u00e4llningar som verkligen spelar roll i vardagen.<\/p>\n\n<h2>Centrala punkter<\/h2>\n<ul>\n  <li><strong>Smutsiga sidor<\/strong> markerar \u00e4ndrade sidor i RAM-minnet som \u00e4nnu inte har sparats p\u00e5 lagringsmediet.<\/li>\n  <li><strong>\u00c5terf\u00f6ring<\/strong> samlar ihop \u00e4ndringar och skriver in dem p\u00e5 ett effektivt s\u00e4tt i st\u00f6rre block.<\/li>\n  <li><strong>Tr\u00f6skelv\u00e4rden<\/strong> Precis som vm.dirty_ratio styr de hastigheten och begr\u00e4nsningen.<\/li>\n  <li><strong>Synkronisering<\/strong> Med fsync\/Flush skyddar man sig mot dataf\u00f6rlust.<\/li>\n  <li><strong>\u00d6vervakning<\/strong> Via \/proc och verktyg visas belastning och f\u00f6rdr\u00f6jningar.<\/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>Hur sidcachen fungerar<\/h2>\n\n<p>Jag l\u00e4ser en fil, k\u00e4rnan placerar data i sidcachen, och senare \u00e5tkomst sker fr\u00e5n <strong>Minne<\/strong> ist\u00e4llet f\u00f6r fr\u00e5n skivan. Vid skrivning markerar systemet de \u00e4ndrade sidorna som <strong>Smutsig<\/strong> och bekr\u00e4ftar ofta anropet omedelbart s\u00e5 att applikationen kan forts\u00e4tta k\u00f6ras. Denna avkoppling minskar v\u00e4ntetiderna, eftersom l\u00e5ngsamma I\/O-\u00e5tkomster inte direkt bromsar varje app. Cachen h\u00e5ller dessutom ofta anv\u00e4nda block tillg\u00e4ngliga och \u00f6kar tr\u00e4fffrekvensen vid \u00e5terkommande \u00e5tkomst. Den som vill f\u00f6rdjupa sig ytterligare hittar bakgrundsinformation i min \u00f6versikt \u00f6ver <a href=\"https:\/\/webhosting.de\/sv\/filsystem-caching-linux-sidcache-cacheboost\/\">Cachelagring i filsystemet<\/a>, som visar vilken roll l\u00e4s- och skrivv\u00e4gar spelar i vardagen.<\/p>\n\n<h2>Dirty Pages: Betydelse och konsekvenser<\/h2>\n\n<p>\u201dDirty Pages\u201d \u00e4r \u00e4ndrade minnessidor som \u00e4nnu inte har sparats permanent och d\u00e4rf\u00f6r endast finns i <strong>RAM<\/strong> finns. S\u00e5 l\u00e4nge de \u00e4r smutsiga b\u00e4r jag en viss <strong>Risk<\/strong>: Ett str\u00f6mavbrott skulle kunna g\u00f6ra dessa \u00e4ndringar ogiltiga. Trots detta uppn\u00e5r jag en h\u00f6gre skrivhastighet p\u00e5 detta s\u00e4tt, eftersom k\u00e4rnan sammanfattar m\u00e5nga sm\u00e5 uppdateringar. Om andelen smutsiga sidor \u00f6kar, \u00f6kar trycket p\u00e5 \u00e5terskrivarna. D\u00e5 kan systemet frig\u00f6ra minne genom att prioritera skrivningen av de ber\u00f6rda sidorna till h\u00e5rddisken.<\/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>\u00c5terf\u00f6ring: Utl\u00f6sande faktorer och f\u00f6rlopp<\/h2>\n\n<p>Writeback startar tidsstyrt, h\u00e4ndelsestyrt och p\u00e5 beg\u00e4ran <strong>Appar<\/strong>. K\u00e4rnan samlar ihop \u201ddirty pages\u201d, skapar l\u00e4mpliga I\/O-sekvenser och skickar dem via blocklagret till <strong>Lagringsenhet<\/strong>. Under processen ingriper filsystem, \u00e5tervinningsprogram och I\/O-schemal\u00e4ggare f\u00f6r att styra ordningsf\u00f6ljd och storlek. Synkroniseringskommandon som fsync s\u00e4kerst\u00e4ller att vissa data sparas s\u00e4kert p\u00e5 lagringsmediet innan processen forts\u00e4tter. Under perioder med h\u00f6g aktivitet ser jag i statistiken en \u00f6kande andel writeback, som sedan sjunker igen efter en flush.<\/p>\n\n<h2>Interna mekanismer: balance_dirty_pages, BDI och Writeback-Worker<\/h2>\n\n<p>Under huven samverkar flera komponenter. Skrivande tr\u00e5dar g\u00e5r igenom <strong>balance_dirty_pages()<\/strong>, som tar h\u00e4nsyn till den aktuella \u201dDirty-Last\u201d, enhetens hastighet och de inst\u00e4llda gr\u00e4nserna. Den reglerar processernas skrivhastighet (throttling) s\u00e5 att bakgrunds-writeback hinner ikapp. Varje <strong>St\u00f6denhet<\/strong>-Kontext (bdi) \u2013 vanligtvis en blockenhet eller ett filsystem-backend \u2013 har egna arbetsk\u00f6er med <strong>Flusher-tr\u00e5dar<\/strong>, som omvandlar \u201dDirty Pages\u201d till ordnade I\/O-f\u00f6rfr\u00e5gningar. Denna f\u00f6rdelning f\u00f6rhindrar att en l\u00e5ngsam enhet bromsar upp alla andra och f\u00f6rb\u00e4ttrar r\u00e4ttvisan mellan arbetsbelastningarna.<\/p>\n\n<p>Begr\u00e4nsningen \u00e4r adaptiv: N\u00e4r jag observerar snabbare skrivare eller st\u00f6rre sammanh\u00e4ngande omr\u00e5den \u00f6kar de till\u00e5tna \u201ddirty\u201d-m\u00e4ngderna tillf\u00e4lligt. Vid trafikstockningar, h\u00f6ga latenser eller m\u00e4ttade k\u00f6er bromsar k\u00e4rnan mer aggressivt och tvingar skrivare att pausa tills buffertutrymmet \u00e5terf\u00e5r andrum. Det \u00e4r just detta samspel som f\u00f6rklarar varf\u00f6r sm\u00e5 parameter\u00e4ndringar kan leda till m\u00e4rkbart olika latensprofiler.<\/p>\n\n<h2>Tr\u00f6skelv\u00e4rden: vm.dirty_background_ratio och vm.dirty_ratio<\/h2>\n\n<p>Jag styr beteendet med tv\u00e5 viktiga gr\u00e4nser som reglerar andelen smutsiga sidor i f\u00f6rh\u00e5llande till <strong>RAM<\/strong> definiera. Om jag \u00f6verskrider bakgrundsv\u00e4rdet b\u00f6rjar k\u00e4rnan i <strong>Bakgrund<\/strong> att skriva. Om jag n\u00e5r den h\u00e5rda gr\u00e4nsen stryper systemet skrivande processer tills tillr\u00e4ckligt med data har spolats tillbaka. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir minnet anv\u00e4ndbart, \u00e4ven om enskilda program genererar stora m\u00e4ngder \u00e4ndringar. Den som arbetar med bytebaserade gr\u00e4nser anger motsvarande *_bytes-parametrar ist\u00e4llet f\u00f6r Ratio-v\u00e4rdena.<\/p>\n\n<h2>Tabell: Relevanta k\u00e4rnparametrar och nyckeltal<\/h2>\n\n<p>Jag anv\u00e4nder ett f\u00e5tal centrala reglage f\u00f6r att p\u00e5 ett m\u00e5linriktat s\u00e4tt styra och synligg\u00f6ra writeback, latens och genomstr\u00f6mning; f\u00f6ljande \u00f6versikt hj\u00e4lper till med att <strong>Klassificering<\/strong> och snabba <strong>Unders\u00f6kning<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parameter\/nyckeltal<\/th>\n      <th>Effekt<\/th>\n      <th>Startv\u00e4rden\/Anm\u00e4rkning<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>vm.dirty_background_ratio \/ vm.dirty_background_bytes<\/td>\n      <td>Startar bakgrunds-writeback n\u00e4r andelen smutsiga sidor \u00f6verskrider detta tr\u00f6skelv\u00e4rde.<\/td>\n      <td>V\u00e4lj ett ganska konservativt v\u00e4rde f\u00f6r servrar, s\u00e5 att Flush startar tidigare.<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_ratio \/ vm.dirty_bytes<\/td>\n      <td>\u00d6vre gr\u00e4ns f\u00f6r \u201dDirty Pages\u201d; fr\u00e5n och med denna gr\u00e4ns begr\u00e4nsas skrivarna.<\/td>\n      <td>F\u00f6r h\u00f6gt \u00f6kar risken f\u00f6r f\u00f6rdr\u00f6jningar, f\u00f6r l\u00e5gt inneb\u00e4r en f\u00f6rlust av genomstr\u00f6mning.<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_writeback_centisekunder<\/td>\n      <td>Intervall under vilket k\u00e4rnan kontrollerar om det finns \u201ddirty pages\u201d f\u00f6r bakgrundsrensning.<\/td>\n      <td>Kortare intervall j\u00e4mnar ut belastningstoppar, men ger upphov till fler v\u00e4ckningar.<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_expire_centisecs<\/td>\n      <td>\u00c5lder fr\u00e5n vilken Dirty Pages anses vara \u201emogna\u201c och prioriteras vid skrivandet.<\/td>\n      <td>H\u00f6gre v\u00e4rden ger en starkare sammanl\u00e4ggning, men minskar samtidigt garantierna f\u00f6r konsistens vid fel.<\/td>\n    <\/tr>\n    <tr>\n      <td>\/proc\/meminfo: Dirty, Writeback<\/td>\n      <td>Aktuellt antal smutsiga eller aktivt \u00e5terf\u00f6rda sidor.<\/td>\n      <td>Anv\u00e4ndbart f\u00f6r realtids\u00f6vervakning under belastningstester.<\/td>\n    <\/tr>\n    <tr>\n      <td>Mount-\/FS-alternativ (t.ex. barri\u00e4rer, journal-l\u00e4ge)<\/td>\n      <td>P\u00e5verkar ordningsf\u00f6ljd, varaktighet och kostnader f\u00f6r enskilda rensningar.<\/td>\n      <td>V\u00e4lj efter filsystem och enhet.<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Jag l\u00e4ser av dessa v\u00e4rden regelbundet och j\u00e4mf\u00f6r dem med I\/O-v\u00e4ntetiderna i Top, iostat eller liknande verktyg <strong>Verktyg<\/strong>. Det ger en tydlig bild av om Writeback i sig \u00e4r begr\u00e4nsat eller om det <strong>F\u00f6rvaring<\/strong> ligger p\u00e5 gr\u00e4nsen.<\/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>\u00d6vervakning och diagnostik: Vad jag m\u00e4ter<\/h2>\n\n<p>Jag kontrollerar f\u00f6rst \/proc\/meminfo och f\u00f6ljer f\u00e4lten \u201dDirty\u201d och \u201dWriteback\u201d medan jag m\u00e5lmedvetet <strong>Last<\/strong> skapar. Om \u201dDirty\u201d stiger kraftigt och f\u00f6rblir h\u00f6gt saknas ofta flusher i r\u00e4tt \u00f6gonblick eller s\u00e5 <strong>Medium<\/strong> \u00e4r fullt utnyttjad. Om Writeback \u00f6kar men Dirty bara minskar l\u00e5ngsamt, bromsar m\u00e5lenheten eller I\/O-v\u00e4gen. Om latensspikar sammanfaller med Writeback-spikar, j\u00e4mnar jag ut intervallet eller s\u00e4nker f\u00f6rh\u00e5llandev\u00e4rdena. F\u00f6r att f\u00e5 en inblick i typiska m\u00f6nster hj\u00e4lper en kort <a href=\"https:\/\/webhosting.de\/sv\/prestandafoerbaettrare-foer-linux-sidcache\/\">Sidcache-booster<\/a>, som sammanfattar de praktiska justeringsskruvarna och m\u00e4tpunkterna.<\/p>\n\n<h2>Ut\u00f6kade m\u00e4tpunkter, vmstat och sp\u00e5rning<\/h2>\n\n<p>F\u00f6rutom \/proc\/meminfo anv\u00e4nder jag detaljerade m\u00e4tv\u00e4rden f\u00f6r att skilja mellan orsak och verkan. I <strong>\/proc\/vmstat<\/strong> F\u00e4lt som nr_dirty, nr_writeback, nr_dirtied och nr_written ger en bild av dynamiken: Hur snabbt blir data \u201dsmutsiga\u201d, och hur snabbt rensas de? Dessutom observerar jag l\u00e4ngden p\u00e5 I\/O-k\u00f6erna och andelen avbrutna sammanfogningsoperationer i blocklagret.<\/p>\n\n<ul>\n  <li>vmstat 1: visar per sekund avvikelser i dirty\/writeback och IO-v\u00e4ntetid (wa),<\/li>\n  <li>\/proc\/pressure\/memory: visar minnesbelastningen, som indirekt utl\u00f6ser writeback,<\/li>\n  <li>Tracepoints (writeback:*) och blockh\u00e4ndelser: avsl\u00f6jar ordningen och storleken p\u00e5 t\u00f6mningarna,<\/li>\n  <li>perf\/ftrace: identifierar flaskhalsar i balance_dirty_pages och Flusher-arbetsk\u00f6er.<\/li>\n<\/ul>\n\n<p>Om jag ser att nr_dirtied konstant ligger h\u00f6gre \u00e4n nr_written \u00e4r det ett tydligt tecken p\u00e5 att det snart kommer att uppst\u00e5 begr\u00e4nsningstryck eller att bakgrundsflushningarna sker f\u00f6r sent. Om topparna i writeback-sp\u00e5rpunkterna sammanfaller med latensstoppar optimerar jag intervall och batchstorlekar.<\/p>\n\n<h2>HDD kontra SSD: Konsekvenser f\u00f6r writeback-designen<\/h2>\n\n<p>P\u00e5 roterande skivor \u00e4r st\u00f6rre, sammanh\u00e4ngande flushar s\u00e4rskilt l\u00f6nsamma, eftersom de sparar in p\u00e5 kostsamma s\u00f6kningar <strong>Undvik<\/strong>. SSD-enheter drar ocks\u00e5 nytta av detta, men h\u00e4r \u00e4r det f\u00f6rdelningen av skrivoperationerna och samspelet med <strong>Styrenhet<\/strong>. Jag undviker ett alltf\u00f6r stort antal sm\u00e5 synkroniseringar s\u00e5 att firmware kan fungera effektivt. Samtidigt l\u00e4gger jag st\u00f6rre vikt vid konsistensbarri\u00e4rer och flush-semantik f\u00f6r SSD-enheter f\u00f6r att verkligen dra nytta av enhetens garantier. Blandade arbetsbelastningar med slumpm\u00e4ssiga l\u00e4sningar och skrivningar reagerar m\u00e4rkbart p\u00e5 sm\u00e5 justeringar av tr\u00f6skelv\u00e4rdena f\u00f6r \u201ddirty\u201d och 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>Enhetscache, t\u00f6mningssemantik och skydd mot str\u00f6mavbrott (PLP)<\/h2>\n\n<p>Huruvida en flush verkligen kvarst\u00e5r beror ocks\u00e5 p\u00e5 <strong>Enhetscache<\/strong> fr\u00e5n. M\u00e5nga enheter lagrar data i sitt eget DRAM-minne. Utan <strong>Skydd mot str\u00f6mf\u00f6rlust (PLP)<\/strong> riskerar jag att f\u00f6rlora data om cachen inte t\u00f6ms i tid. Writeback drar visserligen nytta av enhetens cache, men jag ser till att barri\u00e4rer och t\u00f6mningskommandon respekteras. P\u00e5 system med RAID-kontroller utv\u00e4rderar jag om det finns en batteri- eller flash-backupad cache; i s\u00e5dana fall \u00e4r synkroniserade skrivningar ofta att f\u00f6redra utan att s\u00e4kerheten \u00e4ventyras.<\/p>\n\n<p>Jag g\u00f6r dessutom f\u00f6ljande distinktion: FUA (Force Unit Access) tvingar fram persistens per I\/O, men kostar IOPS. Flush-barri\u00e4rer kan s\u00e4kra flera skrivningar samtidigt. F\u00f6r s\u00e4rskilt kritiska v\u00e4gar (till exempel journaler) accepterar jag FUA\/flush-\u00f6verhead, medan jag l\u00e5ter bulkdata ligga kvar i writeback-str\u00f6mmen. Den som \u00e4ndrar monteringsalternativ eller kontrollerinst\u00e4llningar verifierar d\u00e4refter med belastningstester att den avsedda flush-semantiken fungerar.<\/p>\n\n<h2>Datakonsistens: att anv\u00e4nda fsync, Flush och FUA p\u00e5 r\u00e4tt s\u00e4tt<\/h2>\n\n<p>Jag anv\u00e4nder fsync specifikt f\u00f6r data med h\u00f6g <strong>V\u00e4rde<\/strong>, som beh\u00f6ver en tydlig h\u00e5llbarhetsgaranti. K\u00e4rnan kan driva flush-operationer \u00e4nda fram till lagringsmediet och med hj\u00e4lp av FUA s\u00e4kerst\u00e4lla att en skrivning verkligen <strong>kvarst\u00e5r<\/strong>, innan bekr\u00e4ftelsen kommer tillbaka. Denna metod tar tid och f\u00f6rbrukar IOPS, men f\u00f6rhindrar dataf\u00f6rlust vid systemkrascher. Utan s\u00e5dana barri\u00e4rer rapporterar systemet att transaktionerna har lyckats, trots att bytena fortfarande finns kvar i SSD-enhetens cache eller i RAM-minnet. Jag anpassar dessa beslut efter applikationen: transaktionsloggar sparas med h\u00e5rd s\u00e4kerhet, medan bulkuppdateringar sparas med mjuk s\u00e4kerhet.<\/p>\n\n<h2>Exempel p\u00e5 optimering av webbhotell- och databasarbetsbelastningar<\/h2>\n\n<p>F\u00f6r webb- och databasservrar anv\u00e4nder jag ofta ett m\u00e5ttligt v\u00e4rde p\u00e5 dirty_background_ratio och h\u00e5ller dirty_ratio betydligt h\u00f6gre f\u00f6r att s\u00e4kerst\u00e4lla att bakgrundsrensningen sker i tid <strong>starta<\/strong>, utan att Schreiber g\u00f6r det f\u00f6r tidigt <strong>Broms<\/strong>. Vid skrivspikar s\u00e4nker jag writeback-intervallet s\u00e5 att writeback-mekanismerna aktiveras tidigare. P\u00e5 system med mycket RAM f\u00f6redrar jag *_bytes-v\u00e4rden s\u00e5 att faktiska storlekar anv\u00e4nds ist\u00e4llet f\u00f6r procenttal. Jag testar varje \u00e4ndring med repeterbara prestandatester och m\u00e4ter latens, genomstr\u00f6mning samt 95- och 99-percentilerna. Denna praktiska \u00f6versikt ger mig en kortfattad guide till sidcachens effekt: <a href=\"https:\/\/webhosting.de\/sv\/prestandafoerbaettrare-foer-linux-sidcache\/\">Prestandaf\u00f6rb\u00e4ttrare f\u00f6r Linux-sidcache<\/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 och mmap: N\u00e4r sidcachen kringg\u00e5s<\/h2>\n\n<p>Det \u00e4r inte alla applikationer som anv\u00e4nder sidcachen p\u00e5 samma s\u00e4tt. Med <strong>O_DIRECT<\/strong> kan den medvetet kringg\u00e5 cachen och skriva eller l\u00e4sa direkt till enheten. Det avlastar RAM-minnet och f\u00f6rkortar v\u00e4garna, men jag g\u00e5r d\u00e5 miste om f\u00f6rdelarna med batchning och readahead. F\u00f6r stora, eng\u00e5ngs\u00f6verf\u00f6ringar kan det vara l\u00e4mpligt; vid m\u00e5nga sm\u00e5 skrivningar g\u00e5r d\u00e4remot f\u00f6rdelarna med writeback f\u00f6rlorade.<\/p>\n\n<p>Med <strong>mmap<\/strong> och med Copy-on-Write markerar jag sidor som \u201ddirty\u201d n\u00e4r de \u00e4ndras; t\u00f6mningen sker via den vanliga writeback-v\u00e4gen eller genom <strong>msync<\/strong>. Jag tar h\u00e4nsyn till detta n\u00e4r applikationer i h\u00f6g grad f\u00f6rlitar sig p\u00e5 minnesmappad I\/O: toppar i antalet \u201edirty\u201c data kan uppst\u00e5 ov\u00e4ntat, trots att appen \u201dbara\u201d skriver till minnet. \u00c4ven h\u00e4r kan gr\u00e4nsv\u00e4rden f\u00f6r f\u00f6rh\u00e5llande\/byte hj\u00e4lpa till att styra tidpunkten f\u00f6r skrivningen.<\/p>\n\n<h2>Containermilj\u00f6er och cgroup-Writeback<\/h2>\n\n<p>I milj\u00f6er med flera anv\u00e4ndare f\u00f6rhindrar jag \u201eNoisy Neighbors\u201c genom att <strong>cgroups<\/strong>. K\u00e4rnan tilldelar \u201ddirty pages\u201d till den grupp som orsakat dem (cgroup-Writeback), s\u00e5 att bakgrundsflush och strypning f\u00f6rdelas mer r\u00e4ttvist. Med minnesgr\u00e4nser (<strong>minne.h\u00f6g<\/strong>, memory.max) begr\u00e4nsar jag antalet \u201ddirty-toppar\u201d per container. Dessutom st\u00e4ller jag in I\/O-kvoter via I\/O-kontrollern f\u00f6r att f\u00f6rhindra att enskilda arbetsbelastningar fyller hela enhetens k\u00f6.<\/p>\n\n<p>I praktiken fastst\u00e4ller jag realistiska \u00f6vre gr\u00e4nser f\u00f6r varje serviceklass: Batchjobb med h\u00f6g skrivbelastning tilldelas gener\u00f6sa \u201ddirty budgets\u201d, medan frontend-tj\u00e4nster d\u00e4r latens \u00e4r avg\u00f6rande f\u00e5r sn\u00e4vare gr\u00e4nser. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir den totala latensen mer stabil, eftersom Writeback inte pl\u00f6tsligt stryper hastigheten f\u00f6r alla s\u00e5 fort en enskild container hamnar ur kurs.<\/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>N\u00e4tverksfilsystem (NFS, SMB, distribuerade filsystem)<\/h2>\n\n<p>I n\u00e4tverksfilsystem tillkommer ytterligare en buffertniv\u00e5. Lokala \u201ddirty pages\u201d indikerar endast att data \u00e4r p\u00e5 v\u00e4g; om de <strong>fj\u00e4rrstyrd<\/strong> Det \u00e4r protokollet (commit-semantik) och servern som avg\u00f6r om data ska sparas. Jag litar inte p\u00e5 implicita t\u00f6mningar: kritiska data synkroniserar jag explicit. Samtidigt tar jag h\u00e4nsyn till round-trip-kostnaderna \u2013 alltf\u00f6r frekventa synkroniseringar \u00f6ver n\u00e4tverket f\u00f6rs\u00e4mrar latensen m\u00e4rkbart.<\/p>\n\n<p>Vid blandade arbetsbelastningar separerar jag v\u00e4garna: Lokala, tillf\u00e4lliga filer drar maximal nytta av sidcachen; n\u00e4tverksmonterade enheter f\u00e5r striktare synkroniseringspunkter. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rhindrar jag att skriv\u00e5terf\u00f6ring via n\u00e4tverket blir en flaskhals, medan lokala jobb fortfarande har reserver kvar.<\/p>\n\n<h2>I\/O-schemal\u00e4ggare, blk-mq och k\u00f6djup<\/h2>\n\n<p>Hur effektivt writeback-batcher hamnar p\u00e5 enheten beror ocks\u00e5 p\u00e5 <strong>Blocklager<\/strong> fr\u00e5n. Med <strong>blk-mq<\/strong> I\/O-operationerna f\u00f6rdelas \u00f6ver flera k\u00f6er; schemal\u00e4ggare som mq-deadline eller kyber prioriterar och ordnar dem. Jag v\u00e4ljer schemal\u00e4ggare utifr\u00e5n lagringsmediet: P\u00e5 NVMe \u00e4r \u201enone\u201c ofta l\u00e4mpligt, medan Deadline hj\u00e4lper till att ordna skrivoperationer p\u00e5 SATA eller SAS.<\/p>\n\n<p>Die <strong>K\u00f6nsdjup<\/strong> Jag st\u00e4ller in det s\u00e5 att enheten utnyttjas fullt ut, men inte \u00f6verbelastas. F\u00f6r l\u00e5g djup minskar genomstr\u00f6mningen, medan f\u00f6r djupt \u00f6kar latensspridningen och g\u00f6r strypningen tr\u00f6g. Writeback gynnas av m\u00e5ttliga djup och stora, sammanh\u00e4ngande f\u00f6rfr\u00e5gningar. Jag \u00f6vervakar sammanslagningsfrekvenser och \u201einflight\u201c-r\u00e4knare; sjunkande sammanslagningsfrekvenser tyder p\u00e5 f\u00f6r sm\u00e5 batcher eller konkurrerande slumpm\u00e4ssiga arbetsbelastningar.<\/p>\n\n<h2>Reproducerbara tester och s\u00e4ker \u00e5terst\u00e4llning<\/h2>\n\n<p>Innan jag justerar reglagen dokumenterar jag det aktuella l\u00e4get och testar <strong>Reproducerbar<\/strong> och planerar tillbakag\u00e5ngar. Jag anv\u00e4nder identiska arbetsbelastningar och identiska datam\u00e4ngder och v\u00e4rmer upp cachen p\u00e5 ett m\u00e5linriktat s\u00e4tt eller t\u00f6mmer den medvetet f\u00f6r att g\u00f6ra testk\u00f6rningarna j\u00e4mf\u00f6rbara. Jag g\u00f6r f\u00f6rst tillf\u00e4lliga inst\u00e4llnings\u00e4ndringar, observerar m\u00e4tv\u00e4rdena och sparar dem f\u00f6rst d\u00e4refter permanent.<\/p>\n\n<pre><code># Exempel: tillf\u00e4lliga inst\u00e4llningar (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 (exempel, beroende p\u00e5 arbetsbelastning)\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>Under tiden l\u00e4ser jag av \/proc\/meminfo, vmstat och iostat parallellt och korrelerar toppv\u00e4rdena. Efter testet \u00e5terst\u00e4ller jag v\u00e4rdena eller \u00f6verf\u00f6r dem p\u00e5 ett kontrollerat s\u00e4tt till systemkonfigurationen. I samband med detta dokumenterar jag <strong>datum<\/strong>, <strong>K\u00e4rnan<\/strong>-version, enhets- och filsystemuppgifter, s\u00e5 att senare j\u00e4mf\u00f6relser f\u00f6rblir tillf\u00f6rlitliga.<\/p>\n\n<h2>Vanliga problem och \u00e5tg\u00e4rder<\/h2>\n\n<p>Om systemet verkar fungera smidigt men skrivoperationerna h\u00e4nger sig, kontrollerar jag om det beror p\u00e5 att hastigheten begr\u00e4nsas p\u00e5 grund av att <strong>smutsigt_f\u00f6rh\u00e5llande<\/strong>. Om Dirty forts\u00e4tter p\u00e5 en h\u00f6g niv\u00e5 saknas bandbredd eller s\u00e5 <strong>Intervall<\/strong> till flushen \u00e4r f\u00f6r l\u00e5ng. Om latenserna skjuter i h\u00f6jden vid korta synkroniseringsv\u00e5gor f\u00f6rdelar jag belastningen \u00f6ver mindre batcher och f\u00f6rb\u00e4ttrar I\/O-planeringen. Om cachen knappt kommer ig\u00e5ng kan en f\u00f6r l\u00e5g *_bytes-gr\u00e4ns kanske hindra en meningsfull batchning. En n\u00e4rmare titt p\u00e5 <a href=\"https:\/\/webhosting.de\/sv\/server-page-cache-eviction-linux-minne-utskriftsoptimering-insikt\/\">Cache-utpl\u00e5ning vid utskrift<\/a> \u00e4r till hj\u00e4lp n\u00e4r det dessutom uppst\u00e5r brist p\u00e5 lagringsutrymme.<\/p>\n\n<h2>B\u00e4sta praxis och kort checklista<\/h2>\n\n<p>Jag g\u00f6r en tydlig \u00e5tskillnad mellan data som m\u00e5ste sparas omedelbart och data som kan sparas med viss f\u00f6rdr\u00f6jning, f\u00f6r att <strong>Effekt<\/strong> att vinna. F\u00f6r loggar och transaktionsjournaler tvingar jag fram synkroniseringar; f\u00f6r tillf\u00e4lliga artefakter l\u00e5ter jag writeback k\u00f6ras fritt och h\u00e5ller bara ett \u00f6ga p\u00e5 begr\u00e4nsningsgr\u00e4nsen. Innan varje justering m\u00e4ter jag det aktuella l\u00e4get och j\u00e4mf\u00f6r A\/B utifr\u00e5n definierade scenarier. Jag h\u00e5ller antalet samtidiga skrivare under kontroll, eftersom okoordinerade fl\u00f6den minskar nyttan av batchning. Och jag dokumenterar \u00e4ndringar omedelbart, s\u00e5 att framtida analyser kan baseras p\u00e5 tydliga <strong>Uppgifter<\/strong> baserad.<\/p>\n\n<h2>Praktisk sammanfattning f\u00f6r snabba resultat<\/h2>\n\n<p>Writeback-cachen samlar \u00e4ndringar i <strong>Sidan<\/strong> Cache minskar I\/O-kostnaderna och avlastar applikationerna. \u201dDirty Pages\u201d \u00e4r inget fel, utan ett medvetet verktyg f\u00f6r att \u00f6ka hastigheten, s\u00e5 l\u00e4nge jag k\u00e4nner till gr\u00e4nserna och konsistenskraven. Med parametrarna vm.dirty_background_ratio och vm.dirty_ratio styr jag n\u00e4r k\u00e4rnan arbetar tyst i bakgrunden och n\u00e4r den bromsar skrivoperationer. Verktyg och \/proc ger mig den n\u00f6dv\u00e4ndiga insynen i dirty och writeback, s\u00e5 att jag inte g\u00e5r i blindo. N\u00e4r jag beh\u00e4rskar dessa reglage k\u00f6rs webb, databaser och batchjobb m\u00e4tbart snabbare, utan att <strong>Integritet<\/strong> att \u00e4ventyra mina uppgifter.<\/p>","protected":false},"excerpt":{"rendered":"<p>Writeback-cache i Linux-k\u00e4rnan: Dirty Pages, sidcache och \u00e5terskrivning f\u00f6rklaras p\u00e5 ett l\u00e4ttf\u00f6rst\u00e5eligt s\u00e4tt.<\/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":"153","_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\/sv\/wp-json\/wp\/v2\/posts\/20548","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/comments?post=20548"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/20548\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/20541"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=20548"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=20548"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=20548"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}