{"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\/sv\/linux-dirty-ratio-dirty-background-ratio-optimierung-writeback\/","title":{"rendered":"Linux Dirty Ratio och Dirty Background Ratio: Finjustering f\u00f6r optimal skrivprestanda"},"content":{"rendered":"<p>Jag visar hur <strong>linux dirty<\/strong> och styra sidcachen med hj\u00e4lp av \u201ddirty background ratio\u201d och d\u00e4rmed p\u00e5verka skrivgenomstr\u00f6mning, latens och datas\u00e4kerhet. P\u00e5 s\u00e5 s\u00e4tt fastst\u00e4ller du konkreta gr\u00e4nsv\u00e4rden som startar rensningen i r\u00e4tt tid, f\u00f6rhindrar blockeringar och \u00f6kar skrivprestandan f\u00f6r dina arbetsbelastningar.<\/p>\n\n<h2>Centrala punkter<\/h2>\n<p>Till att b\u00f6rja med sammanfattar jag kort de viktigaste punkterna innan jag g\u00e5r in p\u00e5 detaljerna.<\/p>\n<ul>\n  <li><strong>Oanst\u00e4ndiga sidor<\/strong> buffrar skrivningar i RAM-minnet och sammanf\u00f6r m\u00e5nga sm\u00e5 \u00e5tkomstf\u00f6rfr\u00e5gningar till mer effektiva I\/O-operationer.<\/li>\n  <li><strong>smutsig_bakgrund_f\u00f6rh\u00e5llande<\/strong> startar Flusher-tr\u00e5dar i bakgrunden och begr\u00e4nsar d\u00e4rmed smutsm\u00e4ngden utan att man m\u00e4rker det.<\/li>\n  <li><strong>smutsigt_f\u00f6rh\u00e5llande<\/strong> bromsar skrivprocesser om det fasta gr\u00e4nsv\u00e4rdet \u00f6verskrids.<\/li>\n  <li><strong>Relation<\/strong> B\u00e5da v\u00e4rdena avg\u00f6r latensspikar, genomstr\u00f6mning och buffertstorlek.<\/li>\n  <li><strong>Bytes-varianter<\/strong> (dirty_bytes) ger en mer precis och absolut kontroll p\u00e5 stora servrar.<\/li>\n<\/ul>\n\n<h2>Att f\u00f6rst\u00e5 \u201dDirty Pages\u201d<\/h2>\n\n<p>N\u00e4r en process skriver data hamnar de f\u00f6rst i <strong>Sidans cache<\/strong> och markeras som \u201edirty\u201c tills k\u00e4rnan kan skriva ut dem till lagringsmediet. Denna buffring p\u00e5skyndar applikationer, eftersom RAM-minnet reagerar snabbare \u00e4n n\u00e5gon SSD eller HDD och sm\u00e5 skrivoperationer sammanfogas till stora, sekventiella \u00f6verf\u00f6ringar. Jag \u00e4r alltid medveten om hur mycket \u201esmuts\u201c jag till\u00e5ter, eftersom f\u00f6r mycket buffring kan f\u00f6rl\u00e4nga k\u00f6erna eller inneb\u00e4ra en st\u00f6rre risk f\u00f6r os\u00e4krade data vid systemkrascher. Den som f\u00f6rst\u00e5r hur det fungerar kan fatta b\u00e4ttre beslut om writeback, latens och lagringsbelastning. En kort bakgrundsartikel om <a href=\"https:\/\/webhosting.de\/sv\/writeback-cache-linux-kaernans-cache\/\">Writeback-cache<\/a> hj\u00e4lper till att tydligt f\u00f6rst\u00e5 hur denna mekanism fungerar.<\/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>Datas\u00e4kerhet, fsync och kraschf\u00f6nster<\/h2>\n<p>Gr\u00e4nsv\u00e4rdena p\u00e5verkar inte bara prestandan, utan \u00e4ven ditt riskf\u00f6nster. Jag ber\u00e4knar det med en enkel tumregel: den maximala m\u00e4ngden os\u00e4kra data dividerat med enhetens h\u00e5llbara genomstr\u00f6mning ger ungef\u00e4r den tid det tar tills buffertminnet \u00e4r tomt. Exempel: Om jag till\u00e5ter 4 GB \u201ddirty data\u201d och m\u00e5lmediet n\u00e5r 500 MB\/s, tar den fullst\u00e4ndiga skrivningen cirka 8 sekunder. Under den tiden kan de senaste skrivningarna g\u00e5 f\u00f6rlorade vid str\u00f6mavbrott eller kernelpanik.<\/p>\n<p>Program kan st\u00e4nga f\u00f6nstret genom att <code>fsync()<\/code> eller . <code>fdatasync()<\/code> minska, eftersom dessa \u00e5tkomstf\u00f6rfr\u00e5gningar tvingar filsystemet att skriva data (och, beroende p\u00e5 journalf\u00f6ringsl\u00e4ge, \u00e4ven metadata) till lagringsmediet. Detta \u00e4r mer resurskr\u00e4vande, men n\u00f6dv\u00e4ndigt f\u00f6r databaser eller journaler. Jag ser till att mina \u201ddirty\u201d-gr\u00e4nser st\u00e4mmer \u00f6verens med synkroniseringsbeteendet: Frekventa <code>fsync()<\/code>-Visningarna gynnas av l\u00e4gre <em>smutsigt_f\u00f6rh\u00e5llande<\/em>, s\u00e5 att k\u00e4rnan inte begr\u00e4nsar ytterligare n\u00e4r loggarna \u00e4nd\u00e5 sparas regelbundet. Omv\u00e4nt kan jag till\u00e5ta st\u00f6rre buffertar f\u00f6r loggar med mycket appendering som s\u00e4llan t\u00f6ms \u2013 alltid med h\u00e4nsyn till den accepterade risken f\u00f6r dataf\u00f6rlust.<\/p>\n<p>\u00c4ven barri\u00e4rer och skrivordningsf\u00f6ljd \u00e4r viktiga: Moderna filsystem anv\u00e4nder FUA\/Flush-kommandon f\u00f6r att t\u00f6mma kontrollerns cacheminnen p\u00e5 r\u00e4tt s\u00e4tt. P\u00e5 media utan str\u00f6mavbrottsskydd (PLP) \u00f6kar stora buffertar risken; med PLP eller skrivcache-skydd \u00e4r st\u00f6rre buffertar ofta acceptabla.<\/p>\n\n<h2>Dirty Background Ratio: det mjuka tr\u00f6skelv\u00e4rdet<\/h2>\n\n<p>Med <strong>smutsig_bakgrund_f\u00f6rh\u00e5llande<\/strong> H\u00e4r anger jag fr\u00e5n vilken procentandel av det tillg\u00e4ngliga lagringsutrymmet som flusher-tr\u00e5dar b\u00f6rjar skriva i bakgrunden. Detta v\u00e4rde blockerar inga applikationer, utan startar tyst uppst\u00e4dningsarbetet s\u00e5 att bufferten inte sv\u00e4mmar \u00f6ver. L\u00e5ga siffror ger oftare, men j\u00e4mnare bakgrundsskrivning och j\u00e4mnar ut latensspikar. H\u00f6gre siffror till\u00e5ter st\u00f6rre buffertar, vilket \u00f6kar genomstr\u00f6mningen vid stora sekventiella skrivningar, men kan utl\u00f6sa betydande I\/O-spikar vid pl\u00f6tslig t\u00f6mning. Standardv\u00e4rdena ligger vanligtvis runt tio procent, men jag justerar gr\u00e4nsen beroende p\u00e5 medium, arbetsbelastning och s\u00e4kerhetskrav.<\/p>\n\n<h2>Dirty Ratio: den h\u00e5rda inbromsningen<\/h2>\n\n<p>Parametern <strong>smutsigt_f\u00f6rh\u00e5llande<\/strong> markerar den gr\u00e4ns vid vilken k\u00e4rnan stryper skrivande processer tills tillr\u00e4ckligt m\u00e5nga sidor har skrivits tillbaka. Denna h\u00e5rda gr\u00e4ns skyddar minnet mot en flod av icke-persisterade data och p\u00e5verkar d\u00e4rmed direkt applikationerna s\u00e5 snart de vill forts\u00e4tta producera data. F\u00f6r databaser st\u00e4ller jag in v\u00e4rdet ganska l\u00e5gt, s\u00e5 att f\u00f6rfr\u00e5gningarna beh\u00e5ller konstanta svarstider och inga l\u00e5nga t\u00f6mningsfaser uppst\u00e5r. F\u00f6r s\u00e4kerhetskopieringsjobb anv\u00e4nder jag d\u00e4remot gener\u00f6sare buffertar f\u00f6r att effektivt \u00f6verf\u00f6ra stora block. Vanliga standardv\u00e4rden varierar mellan tjugo och fyrtio procent, men jag anpassar alltid detta intervall efter den faktiska belastningen.<\/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>Samspel och typiska relationer<\/h2>\n\n<p>B\u00e5da gr\u00e4nsv\u00e4rdena fungerar som <strong>Tandem<\/strong> och f\u00e5r f\u00f6rst effekt n\u00e4r de samverkar. Jag h\u00e5ller alltid dirty_background_ratio l\u00e4gre \u00e4n dirty_ratio, s\u00e5 att k\u00e4rnan startar i bakgrunden i god tid och den h\u00e5rda bromsningen s\u00e4llan aktiveras. Som tumregel v\u00e4ljer jag ofta en fj\u00e4rdedel till h\u00e4lften av den h\u00e5rda gr\u00e4nsen, till exempel 5\u201310 mot 20. P\u00e5 s\u00e5 s\u00e4tt startar Writeback tillr\u00e4ckligt tidigt utan att genomstr\u00f6mningen s\u00e4nks i on\u00f6dan. Den som missar detta f\u00f6rh\u00e5llande upplever antingen f\u00f6r tidig strypning eller f\u00f6r sen bakgrundsbearbetning med m\u00e4rkbara latensspikar.<\/p>\n\n<h2>Styrning per enhet och blocklagersuppl\u00f6sning<\/h2>\n<p>F\u00f6rutom de globala gr\u00e4nserna \u00e4r det v\u00e4rt att titta p\u00e5 enhetsniv\u00e5n. Linux f\u00f6rdelar \u201ddirty-last\u201d via s\u00e5 kallade <em>Kompatibla enheter<\/em> (bdi). I <code>\/sys\/class\/block\/\/bdi\/<\/code> Jag tycker att parametrar som <code>max_ratio<\/code>, som avg\u00f6r hur stor del av den totala till\u00e5tna \u201dDirty-Budget\u201d som en enskild enhet f\u00e5r anv\u00e4nda. P\u00e5 system med b\u00e5de l\u00e5ngsamma och snabba enheter begr\u00e4nsar jag de l\u00e5ngsamma enheterna parallellt, s\u00e5 att de inte blir en flaskhals.<\/p>\n<p>Ett annat viktigt moment \u00e4r begr\u00e4nsningen av blocklagret via <code>\/sys\/block\/\/queue\/wbt_lat_usec<\/code> (Writeback Throttling). Med detta siktar jag p\u00e5 en m\u00e5llatens; k\u00e4rnan begr\u00e4nsar d\u00e5 skrivbelastningen om den \u00f6verskrider denna m\u00e5ltid. F\u00f6r SATA-h\u00e5rddiskar anv\u00e4nder jag g\u00e4rna konservativa v\u00e4rden f\u00f6r att s\u00e4kerst\u00e4lla interaktiviteten. P\u00e5 mycket snabba NVMe-enheter inaktiverar eller h\u00f6jer jag m\u00e5llatensen s\u00e5 att kontrollern kan utnyttja sin parallellitet fullt ut. Jag v\u00e4ljer I\/O-schemal\u00e4ggaren (mq-deadline, BFQ, none) efter behov: BFQ \u00e4r till hj\u00e4lp f\u00f6r interaktiva system med blandad belastning, medan <em>ingen<\/em> eller att mq-deadline ofta fungerar b\u00e4st vid rena genomstr\u00f6mningsjobb p\u00e5 NVMe.<\/p>\n<p>Samspelet \u00e4r avg\u00f6rande: Om <em>smutsig_bakgrund_f\u00f6rh\u00e5llande<\/em> \u00c4ven om v\u00e4rdena \u00e4r l\u00e5ga, men enheten begr\u00e4nsas kraftigt via WBT, uppst\u00e5r \u00e4nd\u00e5 synliga flaskhalsar. D\u00e4rf\u00f6r kalibrerar jag b\u00e5da niv\u00e5erna tillsammans \u2013 globala \u201ddirty\u201d-gr\u00e4nser f\u00f6r buffertstorlek och blocklager f\u00f6r latensskydd.<\/p>\n\n<h2>Ratio vs. Bytes: Standardv\u00e4rden och varianter<\/h2>\n\n<p>P\u00e5 system med mycket <strong>RAM<\/strong> Procentv\u00e4rdena v\u00e4xer snabbt till stora absoluta storleksordningar. D\u00e5 f\u00f6redrar jag att inf\u00f6ra absoluta \u00f6vre gr\u00e4nser med dirty_bytes och dirty_background_bytes f\u00f6r att tydligt begr\u00e4nsa buffertm\u00e4ngden till cirka 2\u20138 GB. Detta kopplar bort regleringen fr\u00e5n kraftigt varierande minneskapaciteter och g\u00f6r att m\u00e4ngden icke-lagrad data f\u00f6rblir ber\u00e4kningsbar. Valet f\u00f6rblir dynamiskt: F\u00f6r sm\u00e5 servrar med lite RAM r\u00e4cker ofta procenttal helt och h\u00e5llet. Den som har h\u00f6g kapacitet kan ofta planera b\u00e4ttre med v\u00e4rden i byte.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parametrar<\/th>\n      <th>Betydelse<\/th>\n      <th>Typiska standardv\u00e4rden<\/th>\n      <th>N\u00e4r ska man byta?<\/th>\n      <th>Ledtr\u00e5d<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>vm.dirty_background_ratio<\/td>\n      <td>Start av <strong>Bakgrundsspolning<\/strong> i procent<\/td>\n      <td>\u2248 10%<\/td>\n      <td>Vid latensvariationer eller mycket snabba SSD\/NVMe-enheter<\/td>\n      <td>L\u00e4gre = j\u00e4mnare latens, h\u00f6gre = st\u00f6rre buffert<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_ratio<\/td>\n      <td>H\u00e5rd <strong>Drosselgr\u00e4ns<\/strong> i procent<\/td>\n      <td>\u2248 20\u201340%<\/td>\n      <td>L\u00e4gre f\u00f6r databaser, h\u00f6gre f\u00f6r s\u00e4kerhetskopior<\/td>\n      <td>F\u00f6r h\u00f6gt \u2192 Risk f\u00f6r blockeringar vid flush<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_background_bytes<\/td>\n      <td>Start av bakgrundsrensningen i <strong>Byte<\/strong><\/td>\n      <td>Inaktiverad n\u00e4r Ratio anv\u00e4nds<\/td>\n      <td>Stort RAM-minne, fasta buffertm\u00e5l<\/td>\n      <td>\u00c5sidos\u00e4tter Ratio-parametrar<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_bytes<\/td>\n      <td>Strikt gr\u00e4ns f\u00f6r drossel i <strong>Byte<\/strong><\/td>\n      <td>Inaktiverad n\u00e4r Ratio anv\u00e4nds<\/td>\n      <td>Stort RAM-minne, planerbar \u00f6vre gr\u00e4ns<\/td>\n      <td>\u00c5sidos\u00e4tter Ratio-parametrar<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Arbetsbelastningsscenarier och rekommendationer<\/h2>\n\n<p>Sekventiella skrivbelastningar s\u00e5som <strong>S\u00e4kerhetskopior<\/strong> drar nytta av stora buffertar och m\u00e5ttlig bakgrundsskrivning, eftersom k\u00e4rnan i stort sett kan skriva direkt till mediet. H\u00e4r st\u00e4ller jag ofta in dirty_ratio mellan 30 och 40 procent och dirty_background_ratio mellan 10 och 20 procent. Databaser och sm\u00e5 slumpm\u00e4ssiga I\/O-applikationer m\u00e5r b\u00e4st av f\u00f6ruts\u00e4gbar latens, d\u00e4rf\u00f6r v\u00e4ljer jag 10\u201315 procent h\u00e5rt och 3\u20135 procent mjukt. F\u00f6r blandade webb- och applikationsservrar visar sig 15\u201320 procent h\u00e5rt och 5\u201310 procent mjukt vara en bra kompromiss. Dessa intervall g\u00e4ller som utg\u00e5ngspunkt, d\u00e4refter \u00e4r det de uppm\u00e4tta v\u00e4rdena f\u00f6r just ditt system som g\u00e4ller.<\/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 och monteringsalternativ<\/h2>\n<p>Writeback-v\u00e4gen slutar i filsystemet \u2013 vars strategi p\u00e5verkar latens och s\u00e4kerhet. Ext4 med <em>data=ordnad<\/em> (Standard) skriver anv\u00e4ndardata f\u00f6re journal-commits; <em>data=\u00e5terskrivning<\/em> minskar latensen, men medf\u00f6r risk f\u00f6r att gamla data g\u00e5r f\u00f6rlorade vid krascher. Parametern <code>commit=<\/code> (sekunder) styr hur ofta loggen sparas. Kortare intervall minskar risken f\u00f6r dataf\u00f6rlust, men kr\u00e4ver mer I\/O. XFS anv\u00e4nder en v\u00e4lutvecklad loggdesign; stora <em>logbstorlek<\/em> och l\u00e4mplig alignering underl\u00e4ttar genomstr\u00f6mningsjobb. Btrfs grupperar skrivningar genom \u201dcopy-on-write\u201d \u2013 detta stabiliserar latenserna, men kan leda till fragmentering vid sm\u00e5 slumpm\u00e4ssiga skrivningar och p\u00e5 SSD-enheter med begr\u00e4nsat utrymme. Alternativ som <em>nodatacow<\/em> kan vara till hj\u00e4lp f\u00f6r vissa s\u00f6kv\u00e4gar eller vid riktad defragmentering n\u00e4r latensspikar uppst\u00e5r.<\/p>\n<p>Jag beaktar dessutom <em>relatime<\/em>\/<em>ingen tid<\/em> (minskar antalet skrivningar av metadata), <em>lattid<\/em> (f\u00f6rdr\u00f6jd mtime\/atime \u00e4r mer best\u00e4ndig) och journaliseringsbarri\u00e4rer. Just p\u00e5 RAID-kontroller eller i virtuella maskiner \u00e4r korrekt cache-semantik avg\u00f6rande: Felaktigt inst\u00e4llda skrivcacher g\u00f6r allt arbete med \u201ddirty tuning\u201d meningsl\u00f6st.<\/p>\n\n<h2>Direkt I\/O, O_SYNC och applikationsbeteende<\/h2>\n<p>Det \u00e4r inte alla applikationer som g\u00e5r via sidcachen. Med <code>O_DIRECT<\/code> eller . <code>O_SYNC<\/code>\/<code>O_DSYNC<\/code> Processer som kringg\u00e5r delar av cachen eller kr\u00e4ver omedelbar lagring. Databaser skriver vanligtvis en WAL\/redo-logg synkront och dataomr\u00e5den asynkront. Jag kalibrerar \u201ddirty\u201d-gr\u00e4nser s\u00e4rskilt f\u00f6r asynkrona v\u00e4gar, medan jag garanterar l\u00e5g latens f\u00f6r synkrona v\u00e4gar via snabba journaler (NVMe, dedikerade LUN). N\u00e4r applikationer mycket ofta <code>fsync()<\/code> N\u00e4r man anropar \u00e4r stora buffertar inte s\u00e4rskilt hj\u00e4lpsamma \u2013 latensen beror d\u00e5 mer p\u00e5 styrenheten, k\u00f6djupet och I\/O-schemal\u00e4ggaren \u00e4n p\u00e5 <em>smutsigt_f\u00f6rh\u00e5llande<\/em>.<\/p>\n\n<h2>Praktisk tuning steg f\u00f6r steg<\/h2>\n\n<p>Innan varje \u00e4ndring kontrollerar jag <strong>faktiska v\u00e4rden<\/strong> med <code>sysctl vm.dirty_ratio<\/code> och <code>sysctl vm.dirty_background_ratio<\/code>, f\u00f6r att dokumentera utg\u00e5ngsl\u00e4get. Vid kortvariga tester skriver jag in v\u00e4rdena direkt efter <code>\/proc\/sys\/vm\/<\/code>, till exempel <code>echo 15 &gt; \/proc\/sys\/vm\/dirty_ratio<\/code> och <code>echo 5 &gt; \/proc\/sys\/vm\/dirty_background_ratio<\/code>. Om anpassningen blir best\u00e5ende, sparar jag den i <code>\/etc\/sysctl.conf<\/code> eller . <code>\/etc\/sysctl.d\/*.conf<\/code>. Jag inf\u00f6r \u00e4ndringar med <code>sysctl -p<\/code> omedelbart s\u00e5 att jag kan m\u00e4ta effekten s\u00e5 snart som m\u00f6jligt. Den som f\u00f6rdjupar sig i \u00e4mnet systemregler har nytta av praktiska tips om <a href=\"https:\/\/webhosting.de\/sv\/sysctl-optimering-av-webbhotellsserverns-prestanda\/\">Sysctl-optimering<\/a> p\u00e5 produktiva servrar.<\/p>\n\n<h2>Ber\u00e4kna v\u00e4rden: R\u00e4kneexempel<\/h2>\n<p>Jag b\u00f6rjar g\u00e4rna med konkreta v\u00e4rden. Exempel 1: Webb-\/appserver med 64 GB RAM, NVMe. M\u00e5let \u00e4r j\u00e4mn latens. Jag anv\u00e4nder <code>dirty_background_bytes=1073741824<\/code> (1 GB) och <code>dirty_bytes=3221225472<\/code> (3 GB). Med en kontinuerlig NVMe-genomstr\u00f6mning p\u00e5 2 GB\/s inneb\u00e4r det att det tar cirka 0,5\u20131,5 sekunder att t\u00f6mma \u2013 vilket \u00e4r bra f\u00f6r interaktiva arbetsbelastningar. Exempel 2: Backup-nod med 128 GB RAM, snabb SATA-RAID med 800 MB\/s. Jag v\u00e4ljer <code>dirty_background_ratio=10<\/code>, <code>dirty_ratio=35<\/code>. I absoluta tal \u00e4r det cirka 12,8 GB och 44,8 GB; det tar 16\u201356 sekunder att t\u00f6mma RAID-enheten. Det \u00e4r okej, eftersom uppgiften inte \u00e4r interaktiv.<\/p>\n<p>Exempel 3: Databasserver med 256 GB RAM, separat journal p\u00e5 NVMe, data p\u00e5 SSD-array. Jag s\u00e4tter absoluta gr\u00e4nser f\u00f6r att undvika extremv\u00e4rden: <code>dirty_background_bytes=2147483648<\/code> (2 GB), <code>dirty_bytes=8589934592<\/code> (8 GB). Det g\u00f6r att storleken p\u00e5 kraschf\u00f6nstret kan planeras och minskar pl\u00f6tsliga inbromsningar vid kontrollpunkter.<\/p>\n\n<h2>Tidpunkt f\u00f6r \u00e5terf\u00f6ring och relaterade parametrar<\/h2>\n\n<p>F\u00f6rutom gr\u00e4nsv\u00e4rdena p\u00e5verkar <strong>Timer<\/strong> Writeback-beteendet och d\u00e4rmed anv\u00e4ndarupplevelsen. Med <code>vm.dirty_writeback_centisekunder<\/code> styr jag intervallet med vilket kernel-flushern v\u00e4cks, medan <code>vm.dirty_expire_centisecs<\/code> definierar hur gamla \u201ddirty pages\u201d f\u00e5r bli som mest. Kortare intervall ger oftare, men mindre, t\u00f6mningar, medan l\u00e4ngre intervall sparar I\/O-anrop men medf\u00f6r en risk f\u00f6r st\u00f6rre buntar. Jag justerar dessa v\u00e4rden endast om m\u00e4tningar visar p\u00e5 verkliga nackdelar, till exempel f\u00f6r s\u00e4llsynta t\u00f6mningar p\u00e5 snabba NVMe-enheter. Den som g\u00e5r metodiskt tillv\u00e4ga undviker sv\u00e4ngningar mellan alltf\u00f6r ivrig och alltf\u00f6r tr\u00f6g 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>\u00d6vervakning och finjustering<\/h2>\n\n<p>Efter justeringarna ser jag att <strong>kontinuerlig<\/strong> nyckeltalen f\u00f6r att synligg\u00f6ra framg\u00e5ngar och biverkningar. I <code>\/proc\/meminfo<\/code> kontrollerar jag \u201eDirty\u201c och \u201eWriteback\u201c f\u00f6r att se buffertniv\u00e5er och aktiva flushar. Verktyg som iostat, sar eller atop visar mig genomstr\u00f6mning, k\u00f6er och latenstrender. Den h\u00e4r artikeln ger en bra introduktion till m\u00e4tv\u00e4rden: <a href=\"https:\/\/webhosting.de\/sv\/server-io-vaenta-analysera-iostat-vmstat-metrics-disk\/\">Analysera I\/O-v\u00e4ntetid<\/a>. F\u00f6rst utifr\u00e5n dessa data justerar jag gr\u00e4nserna upp\u00e5t eller ned\u00e5t i sm\u00e5 steg, s\u00e5 att inga ov\u00e4ntade bieffekter uppst\u00e5r.<\/p>\n\n<h2>Containrar, cgroups och r\u00e4ttvis f\u00f6rdelning<\/h2>\n<p>I container-milj\u00f6er delar arbetsbelastningarna p\u00e5 samma k\u00e4rnmekanismer. Cgroup-Writeback ser till att \u201ddirty pages\u201d tilldelas den som orsakat dem. Jag anv\u00e4nder cgroups I\/O-kontroller (blkcg) f\u00f6r att begr\u00e4nsa bandbredd eller IOPS per container om enskilda hyresg\u00e4ster buffrar f\u00f6r aggressivt. Absoluta gr\u00e4nser i byte p\u00e5 v\u00e4rdniv\u00e5 (<em>smutsiga_bytes<\/em>) f\u00f6rhindra att en enskild g\u00e4st slukar hela Dirty-budgeten. Dessutom begr\u00e4nsar jag lagringsutrymmet via <code>minne.max<\/code>, s\u00e5 att Writeback inte f\u00f6rst reagerar vid global belastning. M\u00e5let \u00e4r fortfarande: Ingen g\u00e4stbelastning f\u00e5r orsaka v\u00e4rd\u00f6vergripande begr\u00e4nsningar av <em>smutsigt_f\u00f6rh\u00e5llande<\/em> tvinga fram.<\/p>\n\n<h2>Hostingmilj\u00f6er och virtuella maskiner<\/h2>\n\n<p>I milj\u00f6er med flera klienter och virtuella maskiner \u00e4r jag noga med att <strong>\u00d6verbokning<\/strong> f\u00f6r RAM och I\/O, eftersom procentuella gr\u00e4nser p\u00e5verkar dessa p\u00e5 ett annat s\u00e4tt. Absoluta gr\u00e4nser i byte kan f\u00f6rhindra att enskilda g\u00e4ster bygger upp f\u00f6r mycket buffert och bromsar upp sina grannar. Jag tar h\u00e4nsyn till lagringsdeduplicering, ballooning och kontrollercacher, eftersom de \u00f6verlagrar buffringseffekter. F\u00f6r hanterade servrar l\u00f6nar det sig om leverant\u00f6ren st\u00e4ller in rimliga standardv\u00e4rden, s\u00e5 att kunderna upplever konstanta svarstider. Den som driver egna noder drar nytta av tydligt definierade profilinst\u00e4llningar f\u00f6r varje arbetsbelastningsklass.<\/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>Vanliga missf\u00f6rst\u00e5nd och hinder<\/h2>\n<ul>\n  <li><strong>\u201eSt\u00f6rre buffert = allt h\u00f6gre genomstr\u00f6mning.\u201c<\/strong> Detta g\u00e4ller inte vid arbetsbelastningar med h\u00f6g andel slumpm\u00e4ssiga data eller enheter med l\u00e5g k\u00f6djup. F\u00f6r stora buffertar orsakar flush-bursts och k\u00f6er.<\/li>\n  <li><strong>\u201edirty_ratio p\u00e5verkar inte antalet l\u00e4sningar.\u201c<\/strong> Indirekt sett, ja: Aggressiva \u00e5terskrivningsfaser tr\u00e4nger undan cachesidor och \u00f6kar l\u00e4sf\u00f6rdr\u00f6jningarna.<\/li>\n  <li><strong>\u201eBytes och f\u00f6rnuft kompletterar varandra.\u201c<\/strong> Nej. Om du anv\u00e4nder Bytes-varianter upph\u00e4ver de sina motsvarigheter i Ratio. Var tydlig.<\/li>\n  <li><strong>\u201efsync() g\u00f6r att gr\u00e4nserna f\u00f6r smutsiga filer blir irrelevanta.\u201c<\/strong> Nej. \u00c4ven om frekventa synkroniseringar minskar riskf\u00f6nstret, omfattas resten av belastningen fortfarande av gr\u00e4nsv\u00e4rdena.<\/li>\n  <li><strong>\u201eEtt snabbt lagringsmedium l\u00f6ser allt.\u201c<\/strong> Inte om Block-Layer stryper bandbredden (WBT) eller om filsystemet \u00e4r monterat p\u00e5 ett suboptimalt s\u00e4tt.<\/li>\n  <li><strong>\u201eDrop_caches \u00e4r ett optimeringsverktyg.\u201c<\/strong> Att t\u00f6mma cachen snedvrider m\u00e4tningarna och f\u00f6rv\u00e4rrar latensspikar. I produktionsmilj\u00f6n undviker jag det.<\/li>\n<\/ul>\n\n<h2>Fels\u00f6kning: typiska symptom och \u00e5tg\u00e4rder<\/h2>\n\n<p>Stapla upp <strong>F\u00f6rdr\u00f6jningstoppar<\/strong>, s\u00e4nker jag f\u00f6rst bakgrundstr\u00f6skelv\u00e4rdet s\u00e5 att flushingar startar tidigare och stora skrivv\u00e5gor uppst\u00e5r mer s\u00e4llan. Om applikationer blockeras periodvis \u00e4r den h\u00e5rda gr\u00e4nsen oftast f\u00f6r h\u00f6g eller s\u00e5 klarar lagringsmediet inte de flushing-v\u00e5gor som uppst\u00e5r. I s\u00e5dana fall s\u00e4nker jag dirty_ratio, kontrollerar readahead-inst\u00e4llningarna och tittar p\u00e5 filsystemets journalf\u00f6ringsalternativ. Vid mycket snabb NVMe-h\u00e5rdvara h\u00f6jer jag bakgrundstr\u00f6skeln stegvis f\u00f6r att inte artificiellt begr\u00e4nsa genomstr\u00f6mningen. Efter varje \u00e4ndring f\u00f6ljer jag m\u00e4tresultaten, inte magk\u00e4nslan.<\/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 sammanfattning f\u00f6r praktiken<\/h2>\n\n<p>Med n\u00e5gra f\u00e5 <strong>Justeringsskruvar<\/strong> Jag p\u00e5verkar hur Linux buffrar skrivdata, n\u00e4r flushare startar och n\u00e4r k\u00e4rnan bromsar. Dirty Background Ratio s\u00e4kerst\u00e4ller en smidig rensning, medan Dirty Ratio begr\u00e4nsar RAM-anv\u00e4ndningen mer strikt. F\u00f6rh\u00e5llandet mellan dessa tv\u00e5 v\u00e4rden avg\u00f6r om ditt system inriktar sig p\u00e5 j\u00e4mna latenser eller maximal genomstr\u00f6mning. Jag dokumenterar standardinst\u00e4llningarna, g\u00f6r sm\u00e5 justeringar och utv\u00e4rderar m\u00e4tningarna konsekvent. P\u00e5 s\u00e5 s\u00e4tt skapas en konfiguration som p\u00e5 ett rimligt s\u00e4tt balanserar arbetsbelastning, medium och risk och som i praktiken k\u00e4nns m\u00e4rkbart snabbare.<\/p>","protected":false},"excerpt":{"rendered":"<p>Uppt\u00e4ck hur du med hj\u00e4lp av \u201dlinux dirty ratio\u201d och \u201ddirty background ratio\u201d kan optimera skrivprestandan och k\u00e4rnprestandan p\u00e5 din server p\u00e5 ett m\u00e5linriktat s\u00e4tt samt hantera \u201ddirty pages\u201d p\u00e5 ett effektivt s\u00e4tt.<\/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":"133","_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\/sv\/wp-json\/wp\/v2\/posts\/20858","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=20858"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/20858\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/20851"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=20858"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=20858"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=20858"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}