{"id":16149,"date":"2025-12-23T11:53:06","date_gmt":"2025-12-23T10:53:06","guid":{"rendered":"https:\/\/webhosting.de\/io-scheduler-linux-noop-mq-deadline-bfq-serverboost\/"},"modified":"2025-12-23T11:53:06","modified_gmt":"2025-12-23T10:53:06","slug":"io-scheduler-linux-noop-mq-deadline-bfq-serverboost","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/io-scheduler-linux-noop-mq-deadline-bfq-serverboost\/","title":{"rendered":"I\/O Scheduler Linux: Noop, mq-deadline &amp; BFQ forklaret i hosting"},"content":{"rendered":"<p>I\/O Scheduler Linux bestemmer, hvordan systemet sorterer, prioriterer og sender l\u00e6se- og skriveadgang til SSD, NVMe og HDD til enheden. I denne vejledning forklarer jeg p\u00e5 en praktisk m\u00e5de, hvorn\u00e5r <strong>Noop<\/strong>, <strong>mq-udl\u00f8bsdato<\/strong> og <strong>BFQ<\/strong> er det bedste valg inden for hosting \u2013 inklusive tuning, test og klare handlingstrin.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<ul>\n  <li><strong>Noop<\/strong>: Minimal overhead p\u00e5 SSD\/NVMe og i VM'er<\/li>\n  <li><strong>mq-udl\u00f8bsdato<\/strong>: Afbalanceret latenstid og gennemstr\u00f8mning til servere<\/li>\n  <li><strong>BFQ<\/strong>: Fairness og hurtig reaktion ved multi-user<\/li>\n  <li><strong>blk-mq<\/strong>: Multi-Queue-design til moderne hardware<\/li>\n  <li><strong>Indstilling<\/strong>: Test pr. arbejdsbelastning i stedet for faste regler<\/li>\n<\/ul>\n\n<h2>S\u00e5dan fungerer I\/O Scheduler i Linux-hosting<\/h2>\n\n<p>En Linux-I\/O-scheduler sorterer I\/O-anmodninger i k\u00f8er, udf\u00f8rer sammenl\u00e6gning og beslutter levering til enheden for at <strong>Forsinkelse<\/strong> og \u00f8ge genneml\u00f8bet. Moderne kerner bruger blk-mq, dvs. multi-queue, s\u00e5 flere CPU-kerner kan starte I\/O parallelt. Dette passer til NVMe-SSD'er, der tilbyder mange k\u00f8er og h\u00f8j parallelitet og dermed forkorter ventetiderne. I hosting m\u00f8des ofte brede blandede belastninger: Webservere leverer mange sm\u00e5 l\u00e6sninger, databaser genererer synkroniseringsskrivninger, og sikkerhedskopier genererer streams. Den passende scheduler reducerer k\u00f8er, holder svartider stabile og beskytter <strong>Server<\/strong>-Erfaring under belastning.<\/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\/2025\/12\/linux-io-scheduler-hosting-8391.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>blk-mq i praksis: none vs. noop og kerne-standardindstillinger<\/h2>\n\n<p>Siden Kernel 5.x er multi-queue-designet standardvejen. Her er <strong>ingen<\/strong> \u201eNoop\u201c-\u00e6kvivalenten til blk-mq, mens <strong>nej<\/strong> historisk stammer fra single-queue-stien. P\u00e5 NVMe-enheder er det oftest kun <code>ingen<\/code> tilg\u00e6ngelig; p\u00e5 SATA\/SAS ser man ofte <code>mq-udl\u00f8bsdato<\/code>, valgfrit <code>bfq<\/code> og afh\u00e6ngigt af distributionen ogs\u00e5 <code>kyber<\/code>. Standardindstillingerne varierer: NVMe starter som regel med <code>ingen<\/code>, SCSI\/SATA ofte med <code>mq-udl\u00f8bsdato<\/code>. Derfor tjekker jeg altid de tilg\u00e6ngelige muligheder via <code>cat \/sys\/block\/\/queue\/scheduler<\/code> og tr\u00e6f en beslutning for hvert enkelt apparat. Hvor kun <code>ingen<\/code> kan v\u00e6lges, er det med vilje \u2013 yderligere sortering giver praktisk talt ingen merv\u00e6rdi.<\/p>\n\n<h2>Noop i serverbrug: N\u00e5r minimalisme vinder<\/h2>\n\n<p>Noop udf\u00f8rer prim\u00e6rt sammenl\u00e6gning af tilst\u00f8dende blokke, men sorterer ikke, hvilket g\u00f8r CPU-overhead ekstremt <strong>lav<\/strong> holder. P\u00e5 SSD'er og NVMe overtager controllere og firmware den intelligente r\u00e6kkef\u00f8lge, s\u00e5 yderligere sortering i kernen n\u00e6ppe giver nogen fordel. I VM'er og containere planl\u00e6gger jeg ofte Noop, fordi hypervisoren alligevel planl\u00e6gger p\u00e5 tv\u00e6rs. P\u00e5 rotationsplader undg\u00e5r jeg Noop, da manglende sortering \u00f8ger s\u00f8getiderne der. Hvis du vil afgr\u00e6nse hardwarekonteksten sikkert, skal du f\u00f8rst se p\u00e5 hukommelsestypen \u2013 her hj\u00e6lper det at kigge p\u00e5 <a href=\"https:\/\/webhosting.de\/da\/nvme-ssd-hdd-webhosting-sammenligning-ydeevne-omkostninger-tips-serverprofi\/\">NVMe, SSD og HDD<\/a>, f\u00f8r jeg starter Scheduler <strong>fastl\u00e6gge<\/strong>.<\/p>\n\n<h2>mq-deadline: Frister, r\u00e6kkef\u00f8lger og klare prioriteter<\/h2>\n\n<p>mq-deadline giver l\u00e6seadgang korte deadlines og lader skriveadgang vente lidt l\u00e6ngere for at <strong>Svartid<\/strong> m\u00e6rkbart. Scheduleren sorterer desuden efter blokadresser og reducerer dermed s\u00f8getiderne, hvilket is\u00e6r hj\u00e6lper HDD'er og RAID-konfigurationer. I web- og databasehosts leverer mq-deadline en god balance mellem latenstid og gennemstr\u00f8mning. Jeg bruger det gerne, n\u00e5r arbejdsbelastningen er blandet, og der b\u00e5de er l\u00e6sninger og skrivninger, der venter permanent. Til finjustering kontrollerer jeg anmodningsdybde, writeback-adf\u00e6rd og controller-cache, s\u00e5 deadline-logikken er konsistent. <strong>griber<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/linux_io_scheduler_meeting_4273.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>BFQ: Fairness og reaktionsgl\u00e6de for mange samtidige brugere<\/h2>\n\n<p>BFQ fordeler b\u00e5ndbredden proportionalt og tildeler budgetter pr. proces, hvilket m\u00e6rkes <strong>Fair<\/strong> virker, n\u00e5r mange brugere genererer I\/O parallelt. Interaktive opgaver som admin-shells, editorer eller API-kald forbliver hurtige, selvom der k\u00f8rer backups i baggrunden. P\u00e5 HDD'er opn\u00e5r BFQ ofte h\u00f8j effektivitet, fordi det udnytter sekventielle faser og bruger korte inaktive vinduer p\u00e5 en smart m\u00e5de. P\u00e5 meget hurtige SSD'er opst\u00e5r der en lille ekstra belastning, som jeg vejer op mod den m\u00e6rkbare reaktionshastighed. Hvis du bruger Cgroups og ioprio, kan du med BFQ skabe klare garantier og dermed undg\u00e5 problemer med st\u00f8jende naboer. <strong>Undg\u00e5 at<\/strong>.<\/p>\n\n<h2>QoS i hverdagen: ioprio, ionice og Cgroups v2 med BFQ<\/h2>\n\n<p>For ren <strong>Prioritering<\/strong> kombinerer jeg BFQ med proces- og cgroup-regler. P\u00e5 procesniveau indstiller jeg med <code>ionice<\/code> Kategorier og prioriteter: <code>ionice -c1<\/code> (Realtime) for latenstidskritiske l\u00e6sninger, <code>ionice -c2 -n7<\/code> (Best-Effort, lav) til sikkerhedskopieringer eller indeksk\u00f8rsler, <code>ionice -c3<\/code> (Idle) til alt, der kun skal k\u00f8re i tomgang. I Cgroups v2 bruger jeg <code>io.v\u00e6gt<\/code> for relative andele (f.eks. 100 mod 1000) og <code>io.max<\/code> for h\u00e5rde gr\u00e6nser, f.eks. <code>echo \"259:0 rbps=50M wbps=20M\" &gt; \/sys\/fs\/cgroup\/\/io.max<\/code>. Med BFQ omdannes v\u00e6gte meget pr\u00e6cist til b\u00e5ndbreddeandele \u2013 ideelt til shared hosting og containerhosts, hvor <strong>Retf\u00e6rdighed<\/strong> er vigtigere end maksimal r\u00e5styrke.<\/p>\n\n<h2>Praksis sammenligning: Hvilket valg passer til hardware<\/h2>\n\n<p>Valget afh\u00e6nger i h\u00f8j grad af hukommelsestypen og k\u00f8arkitekturen, s\u00e5 jeg tjekker f\u00f8rst <strong>Enhed<\/strong> og controllere. SSD og NVMe drager oftest fordel af Noop\/none, mens HDD'er k\u00f8rer bedre med mq-deadline eller BFQ. I RAID-ops\u00e6tninger, SAN'er og allround-v\u00e6rter foretr\u00e6kker jeg ofte mq-deadline, fordi deadline-logik og sortering harmonerer godt. Multi-bruger-milj\u00f8er med mange interaktive sessioner vinder ofte ved at bruge BFQ. F\u00f8lgende tabel opsummerer styrkerne og de meningsfulde anvendelsesomr\u00e5der p\u00e5 en overskuelig m\u00e5de <strong>sammen<\/strong>:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>planl\u00e6gningsprogram<\/th>\n      <th>Hardware<\/th>\n      <th>Styrker<\/th>\n      <th>Svagheder<\/th>\n      <th>Hosting-scenarier<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Nej\/ingen<\/td>\n      <td>SSD, NVMe, VM'er<\/td>\n      <td>Minimal overhead, ren sammenfletning<\/td>\n      <td>Uden sortering p\u00e5 HDD'er er det en ulempe<\/td>\n      <td>Flash-server, container, hypervisor-styret<\/td>\n    <\/tr>\n    <tr>\n      <td>mq-udl\u00f8bsdato<\/td>\n      <td>HDD, RAID, allround-server<\/td>\n      <td>Streng l\u00e6seprioritet, sortering, solid latenstid<\/td>\n      <td>Mere logik end Noop<\/td>\n      <td>Databaser, web-backends, blandede belastninger<\/td>\n    <\/tr>\n    <tr>\n      <td>BFQ<\/td>\n      <td>HDD, multi-bruger, desktop-lignende v\u00e6rter<\/td>\n      <td>Fairness, reaktionsgl\u00e6de, gode sekvenser<\/td>\n      <td>Lidt mere overhead p\u00e5 meget hurtige SSD'er<\/td>\n      <td>Interaktive tjenester, delt hosting, Dev-server<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/linux-io-scheduler-hosting-4397.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Konfiguration: Kontroller scheduler og indstil permanent<\/h2>\n\n<p>F\u00f8rst ser jeg, hvilken scheduler der er aktiv, f.eks. med <code>cat \/sys\/block\/sdX\/queue\/scheduler<\/code>, og noter <strong>Mulighed<\/strong> i kantede parenteser. For at skifte midlertidigt skriver jeg for eksempel <code>echo mq-deadline | sudo tee \/sys\/block\/sdX\/queue\/scheduler<\/code>. Til permanente indstillinger bruger jeg udev-regler eller kerneparametre som <code>scsi_mod.use_blk_mq=1<\/code> og <code>mq-udl\u00f8bsdato<\/code> i kommandolinjen. For NVMe-enheder kontrollerer jeg stier under <code>\/sys\/block\/nvme0n1\/queue\/<\/code> og indstil valget pr. enhed. Vigtigt: Jeg dokumenterer \u00e6ndringer, s\u00e5 vedligeholdelse og rollback kan foreg\u00e5 uden g\u00e6tterier. <strong>lykkes<\/strong>.<\/p>\n\n<h2>Persistens og automatisering i driften<\/h2>\n\n<p>I hverdagen prioriterer jeg gentagelighed frem for automatisering. Tre metoder har vist sig at v\u00e6re effektive:<\/p>\n<ul>\n  <li><strong>udev-regler<\/strong>: Eksempel for alle HDD'er (rotational=1) <code>echo 'ACTION==\"add|change\", KERNEL==\"sd*\", ATTR{queue\/rotational}==\"1\", ATTR{queue\/scheduler}=\"mq-deadline\"' &gt; \/etc\/udev\/rules.d\/60-io-scheduler.rules<\/code>, s\u00e5 <code>udevadm control --reload-rules &amp;&amp; udevadm trigger<\/code>.<\/li>\n  <li><strong>systemd-tmpfiles<\/strong>: For specifikke enheder definerer jeg <code>\/etc\/tmpfiles.d\/blk.conf<\/code> med linjer som <code>w \/sys\/block\/sdX\/queue\/scheduler - - - - mq-deadline<\/code>, der skriver ved opstart.<\/li>\n  <li><strong>Konfigurationsstyring<\/strong>: I Ansible\/Salt opretter jeg enhedsklasser (NVMe, HDD) og distribuerer konsistente standardindstillinger sammen med dokumentation og rollback.<\/li>\n<\/ul>\n<p>Bem\u00e6rk: <code>elevator=<\/code> som kerneparameter gjaldt for den gamle single-queue-sti. I blk-mq bestemmer jeg valget <strong>pr. enhed<\/strong>. Ved stakke (dm-crypt, LVM, MD) indstiller jeg standarden p\u00e5 top-enheden, mere om dette nedenfor.<\/p>\n\n<h2>Arbejdsbelastninger i hosting: Genkend m\u00f8nstre og handle korrekt<\/h2>\n\n<p>F\u00f8rst analyserer jeg belastningen: Mange sm\u00e5 l\u00e6sninger tyder p\u00e5 webfrontends, synkroniseringsintensive skrivninger p\u00e5 databaser og log-pipelines, store sekventielle streams p\u00e5 sikkerhedskopier eller <strong>Arkiv<\/strong>. V\u00e6rkt\u00f8jer som <code>iostat<\/code>, <code>vmstat<\/code> og <code>blktrace<\/code> viser k\u00f8er, ventetider og sammenfletningseffekter. Ved p\u00e5faldende CPU-inaktivitet p\u00e5 grund af I\/O henviser jeg til <a href=\"https:\/\/webhosting.de\/da\/io-wait-forsta-hukommelsesflaskehals-lose-optimering\/\">Forst\u00e5 I\/O-ventetid<\/a>, for at afhj\u00e6lpe flaskehalse p\u00e5 en struktureret m\u00e5de. Derefter tester jeg 1\u20132 kandidater til planl\u00e6gningsprogrammet i identiske tidsvinduer. Det er m\u00e5leresultaterne, der afg\u00f8r, ikke mavefornemmelsen eller <strong>Myter<\/strong>.<\/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\/2025\/12\/linux_scheduler_hosting_4827.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Uddyb m\u00e5lepraksis: reproducerbare benchmarks<\/h2>\n\n<p>For at tr\u00e6ffe holdbare beslutninger bruger jeg kontrollerede <strong>fio<\/strong>-profiler og bekr\u00e6ft med \u00e6gte applikationstests:<\/p>\n<ul>\n  <li><strong>Tilf\u00e6ldige l\u00e6sninger<\/strong> (Web\/cache): <code>fio --name=rr --rw=randread --bs=4k --iodepth=32 --numjobs=4 --runtime=120 --time_based --filename=\/mnt\/testfile --direct=1<\/code><\/li>\n  <li><strong>Tilf\u00e6ldig blanding<\/strong> (DB): <code>fio --name=randmix --rw=randrw --rwmixread=70 --bs=8k --iodepth=64 --numjobs=8 --runtime=180 --time_based --direct=1<\/code><\/li>\n  <li><strong>Sekventielt<\/strong> (Backup): <code>fio --name=seqw --rw=write --bs=1m --iodepth=128 --numjobs=2 --runtime=120 --time_based --direct=1<\/code><\/li>\n<\/ul>\n<p>Samtidig logger jeg ind <code>iostat -x 1<\/code>, <code>pidstat -d 1<\/code> og noter P95\/P99-latenser fra <code>fio<\/code>. Til dybdeg\u00e5ende diagnoser bruger jeg <code>blktrace<\/code> eller eBPF-v\u00e6rkt\u00f8jer som <code>biolatency<\/code> . Vigtigt: Jeg m\u00e5ler p\u00e5 samme tidspunkter af dagen, med samme belastningsvinduer og samme filst\u00f8rrelser. Jeg minimerer cache-effekter med <code>direct=1<\/code> og rene foruds\u00e6tninger (f.eks. forudfyldning p\u00e5 volumen).<\/p>\n\n<h2>Filsystemer og I\/O-planl\u00e6gning: Samspillet er afg\u00f8rende<\/h2>\n\n<p>Filsystemet p\u00e5virker I\/O-karakteristikken, s\u00e5 jeg tjekker dets journal-tilstand, k\u00f8-dybde og synkroniseringsadf\u00e6rd meget n\u00f8je. <strong>pr\u00e6cis<\/strong>. EXT4 og XFS arbejder effektivt med mq-deadline, mens ZFS selv bufferer og aggregerer meget. P\u00e5 v\u00e6rter med ZFS observerer jeg ofte, at scheduler-effekten er mindre, fordi ZFS allerede former outputtet. Til sammenligninger bruger jeg identiske mount-indstillinger og workloads. Hvis man overvejer forskellige indstillinger, finder man i <a href=\"https:\/\/webhosting.de\/da\/ext4-xfs-zfs-hosting-ydeevne-sammenligning-storage\/\">EXT4, XFS eller ZFS<\/a> nyttige perspektiver p\u00e5 <strong>Opbevaring<\/strong>-Tuning.<\/p>\n\n<h2>Writeback, cache og barrierer: den ofte oversete halvdel<\/h2>\n\n<p>Schedulere kan kun fungere s\u00e5 godt, som writeback-undersystemet tillader det. Derfor tjekker jeg altid:<\/p>\n<ul>\n  <li><strong>dirty-parameter<\/strong>: <code>sysctl vm.dirty_background_bytes<\/code>, <code>vm.dirty_bytes<\/code>, <code>vm.dirty_expire_centisecs<\/code> styre, hvorn\u00e5r og hvor aggressivt kernen skriver. For databaser s\u00e6nker jeg ofte burst-spidser for at holde P99 stabil.<\/li>\n  <li><strong>Barrierer\/Flush<\/strong>: Valgmuligheder som EXT4 <code>barriere<\/code> eller XFS Default-Flushes sikrer jeg kun, hvis hardware (f.eks. BBWC) overtager dem. \u201enobarrier\u201c uden str\u00f8mbeskyttelse er <strong>risikabel<\/strong>.<\/li>\n  <li><strong>Enhedens skrivecache<\/strong>: Jeg verificerer controllerens skrivecacheindstillinger, s\u00e5 <code>fsync<\/code> virkelig ender p\u00e5 mediet og ikke kun i cachen.<\/li>\n<\/ul>\n<p>Ved at udj\u00e6vne Writeback aflastes Scheduler \u2013 deadlines forbliver p\u00e5lidelige, og BFQ beh\u00f8ver ikke at arbejde s\u00e5 h\u00e5rdt mod pludselige flush-b\u00f8lger.<\/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\/2025\/12\/linux_io_scheduler_4813.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Virtualisering, containere og cloud: Hvem planl\u00e6gger egentlig?<\/h2>\n\n<p>I VM'er styrer hypervisoren den fysiske I\/O-str\u00f8m, hvorfor jeg ofte v\u00e6lger Noop\/none i g\u00e6sten for at undg\u00e5 dobbeltarbejde. <strong>logik<\/strong> at undg\u00e5. P\u00e5 selve v\u00e6rten bruger jeg mq-deadline eller BFQ afh\u00e6ngigt af enheden og opgaven. Ved cloud-volumener (f.eks. netv\u00e6rksbloklager) ligger dele af planl\u00e6gningen i backend; derfor m\u00e5ler jeg reelle latenstider i stedet for at stole p\u00e5 antagelser. For container-v\u00e6rter med st\u00e6rkt blandet belastning giver BFQ ofte bedre interaktivitet. I homogene batch-klynger med flash-only vinder Noop, fordi hver CPU-tid t\u00e6ller, og controllere er effektive. <strong>arbejde<\/strong>.<\/p>\n\n<h2>RAID, LVM, MD og Multipath: hvor scheduleren tr\u00e6der i kraft<\/h2>\n\n<p>I stablede blokstakke s\u00e6tter jeg scheduleren p\u00e5 <strong>Top-enhed<\/strong> , for det er der, de relevante k\u00f8er findes:<\/p>\n<ul>\n  <li><strong>LVM\/dm-crypt<\/strong>: Scheduler p\u00e5 <code>\/dev\/dm-*<\/code> hhv. <code>\/dev\/mapper\/<\/code> s\u00e6tte. De fysiske PV'er lader jeg for det meste v\u00e6re p\u00e5 <code>ingen<\/code>, s\u00e5 sammenl\u00e6gning\/sortering ikke sker to gange.<\/li>\n  <li><strong>MD-RAID<\/strong>: Am <code>\/dev\/mdX<\/code> beslutte; darunterliegende <code>sdX<\/code> Enheder forbliver rolige <code>ingen<\/code>. Hardware-RAID behandles som en enkelt blokenhed.<\/li>\n  <li><strong>Multipath<\/strong>: P\u00e5 Multipath-Mapper (<code>\/dev\/mapper\/mpatha<\/code>); sti-enheder under <code>ingen<\/code>.<\/li>\n<\/ul>\n<p>Vigtigt: Jeg adskiller test efter <strong>Pool<\/strong> og redundansniveau (RAID1\/10 vs. RAID5\/6). Paritets-RAID'er er mere f\u00f8lsomme over for tilf\u00e6ldige skrivninger; her vinder mq-deadline ofte takket v\u00e6re konsekvente l\u00e6sefrister og ordnet output.<\/p>\n\n<h2>Tuning-strategier: Trin for trin mod p\u00e5lidelig ydeevne<\/h2>\n\n<p>Jeg starter med en basism\u00e5ling: aktuelle responstider, gennemstr\u00f8mning, 95.\/99.-percentil og CPU-<strong>Belastning<\/strong>. Derefter \u00e6ndrer jeg kun \u00e9n faktor, typisk scheduleren, og gentager den samme belastning. V\u00e6rkt\u00f8jer som <code>fio<\/code> hj\u00e6lper med at kontrollere, men jeg bekr\u00e6fter hver hypotese med reelle applikationstests. Til databaser er det hensigtsm\u00e6ssigt at bruge egne benchmarks, der afspejler transaktioner og fsync-adf\u00e6rd. F\u00f8rst n\u00e5r m\u00e5lingen er stabil, fastl\u00e6gger jeg valget og dokumenterer det. <strong>Hvorfor?<\/strong>.<\/p>\n\n<h2>K\u00f8dybde, forudl\u00e6sning og CPU-affinitet<\/h2>\n\n<p>Ud over scheduler har k\u00f8parametre stor indflydelse p\u00e5 praksis:<\/p>\n<ul>\n  <li><strong>K\u00f8dybde<\/strong>: <code>\/sys\/block\/\/queue\/nr_requests<\/code> Begr\u00e6nser ventende anmodninger pr. hardware-k\u00f8. NVMe t\u00e5ler stor dybde (h\u00f8j gennemstr\u00f8mning), mens HDD'er drager fordel af moderat dybde (mere stabil latenstid).<\/li>\n  <li><strong>Readahead<\/strong>: <code>\/sys\/block\/\/queue\/read_ahead_kb<\/code> hhv. <code>blockdev --getra\/setra<\/code>. Hold den lidt h\u00f8jere for sekventielle arbejdsbelastninger og lav for tilf\u00e6ldige arbejdsbelastninger.<\/li>\n  <li><strong>rq_affinity<\/strong>Med <code>\/sys\/block\/\/queue\/rq_affinity<\/code> p\u00e5 2 s\u00f8rger jeg for, at I\/O-Completion fortrinsvis lander p\u00e5 den genererende CPU-kerne \u2013 det reducerer cross-CPU-omkostningerne.<\/li>\n  <li><strong>rotations<\/strong>: Jeg bekr\u00e6fter, at SSD'er <code>rotation=0<\/code> meddel, s\u00e5 kernen ikke anvender HDD-heuristikker.<\/li>\n  <li><strong>Fusioner<\/strong>: <code>\/sys\/block\/\/queue\/nomerges<\/code> kan reducere sammenl\u00e6gninger (2=fra). Nogle gange nyttigt for NVMe-mikrolatens, men oftest uheldigt for HDD'er.<\/li>\n  <li><strong>io_poll<\/strong> (NVMe): Polling kan reducere latenstider, men kr\u00e6ver CPU. Jeg aktiverer det m\u00e5lrettet ved <strong>Lav latenstid<\/strong>-Krav.<\/li>\n<\/ul>\n\n<h2>Scheduler-tunables i detaljer<\/h2>\n\n<p>Afh\u00e6ngigt af scheduler er der nyttige finjusteringsmuligheder til r\u00e5dighed:<\/p>\n<ul>\n  <li><strong>mq-udl\u00f8bsdato<\/strong>: <code>\/sys\/block\/\/queue\/iosched\/read_expire<\/code> (ms, typisk lille), <code>write_expire<\/code> (st\u00f8rre), <code>fifo_batch<\/code> (batchst\u00f8rrelse), <code>front_merges<\/code> (0\/1). Jeg mener <code>read_expire<\/code> kort for at beskytte P95-reads, og juster <code>fifo_batch<\/code> afh\u00e6ngigt af enheden.<\/li>\n  <li><strong>BFQ<\/strong>: <code>slice_idle<\/code> (Idle-tid til sekvensbrug), <code>lav_latens<\/code> (0\/1) for reaktionsfreudige Interaktivit\u00e4t. Med <code>bfq.v\u00e6gt<\/code> I Cgroups styrer jeg relative andele meget pr\u00e6cist.<\/li>\n  <li><strong>ingen\/noop<\/strong>: N\u00e6sten ingen justeringsskruer, men <strong>Omgivelser<\/strong> (K\u00f8dybde, Readahead) afg\u00f8r resultaterne.<\/li>\n<\/ul>\n<p>Jeg \u00e6ndrer altid kun \u00e9n parameter og registrerer \u00e6ndringen n\u00f8je \u2013 p\u00e5 den m\u00e5de er det klart, hvad der har haft hvilken effekt.<\/p>\n\n<h2>Hyppige faldgruber og hvordan jeg undg\u00e5r dem<\/h2>\n\n<p>Blandede pools af HDD og SSD bag en RAID-controller forvr\u00e6nger testresultaterne, derfor adskiller jeg m\u00e5lingerne pr. <strong>Gruppe<\/strong>. Jeg glemmer ikke, at scheduleren g\u00e6lder pr. blokenhed \u2013 jeg betragter LVM-mapper og MD-enheder separat. Persistens glider let igennem: Uden udev-regel eller kerneparameter er standardindstillingen tilbage efter genstart. Cgroups og I\/O-prioriteter forbliver ofte ubrugte, selvom de \u00f8ger retf\u00e6rdigheden betydeligt. Og jeg tjekker altid k\u00f8dybde, writeback og filsystemindstillinger, s\u00e5 den valgte logik udnytter sit potentiale. <strong>viser<\/strong>.<\/p>\n\n<h2>Fejlfinding: L\u00e6s symptomerne n\u00f8je<\/h2>\n\n<p>N\u00e5r m\u00e5lev\u00e6rdierne \u00e6ndrer sig, tolker jeg m\u00f8nstre og udleder konkrete skridt:<\/p>\n<ul>\n  <li><strong>H\u00f8j P99-latens ved mange l\u00e6sninger<\/strong>: Kontroller, om writes fortr\u00e6nger reads. Test med mq-deadline., <code>read_expire<\/code> s\u00e6nke, udj\u00e6vne writeback (<code>vm.dirty_*<\/code> tilpasse).<\/li>\n  <li><strong>100% util p\u00e5 HDD, lav gennemstr\u00f8mning<\/strong>: S\u00f8ger dominerer. Pr\u00f8v BFQ eller mq-deadline, reducer Readahead, moderer k\u00f8dybden.<\/li>\n  <li><strong>Gode genneml\u00f8bsv\u00e6rdier, men UI hakker<\/strong>: Interaktiviteten lider under det. Aktiver BFQ, kritiske tjenester via <code>ionice -c1<\/code> eller Cgroup-v\u00e6gte.<\/li>\n  <li><strong>Stor variation afh\u00e6ngigt af tidspunktet p\u00e5 dagen<\/strong>: Delte ressourcer. Isol\u00e9r med Cgroups, v\u00e6lg scheduler pr. pool, flyt backups til off-peak.<\/li>\n  <li><strong>NVMe-timeouts i dmesg<\/strong>: Backend eller firmware-tema. <code>io_poll<\/code> Deaktiver det p\u00e5 pr\u00f8vebasis, kontroller firmware\/driver, verificer sti-redundans (multipath).<\/li>\n<\/ul>\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\/2025\/12\/linux-io-hosting-9481.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kort sagt: Klare beslutninger til hverdagen inden for hosting<\/h2>\n\n<p>Til flash-lager og g\u00e6ster v\u00e6lger jeg ofte <strong>Noop<\/strong>, for at spare overhead og lade controllere arbejde. I allround-servere med HDD eller RAID leverer mq-deadline p\u00e5lidelig latenstid og h\u00f8j brugbarhed. Ved mange aktive brugere og interaktiv belastning sikrer BFQ fair fordeling og m\u00e6rkbar reaktionshastighed. F\u00f8r hver fastl\u00e6ggelse m\u00e5ler jeg med reelle arbejdsbelastninger og observerer effekterne p\u00e5 P95\/P99. P\u00e5 den m\u00e5de tr\u00e6ffer jeg forst\u00e5elige beslutninger, holder systemerne k\u00f8rende og stabiliserer <strong>Server<\/strong>-Pr\u00e6station i den daglige drift.<\/p>","protected":false},"excerpt":{"rendered":"<p>I\/O Scheduler Linux forklaret: noop, mq-deadline &amp; BFQ for optimal hosting. Tips til storage tuning for serverperformance.<\/p>","protected":false},"author":1,"featured_media":16142,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-16149","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":"1822","_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":null,"_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":"I\/O Scheduler Linux","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":"16142","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/16149","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=16149"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/16149\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/16142"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=16149"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=16149"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=16149"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}