{"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\/nl\/io-scheduler-linux-noop-mq-deadline-bfq-serverboost\/","title":{"rendered":"I\/O Scheduler Linux: Noop, mq-deadline &amp; BFQ in hosting uitgelegd"},"content":{"rendered":"<p>De I\/O Scheduler Linux bepaalt hoe het systeem lees- en schrijftoegang tot SSD, NVMe en HDD sorteert, prioriteert en naar het apparaat verzendt. In deze handleiding leg ik op praktische wijze uit wanneer <strong>Noop<\/strong>, <strong>mq-deadline<\/strong> en <strong>BFQ<\/strong> de beste keuze zijn voor hosting \u2013 inclusief tuning, tests en duidelijke stappenplan.<\/p>\n\n<h2>Centrale punten<\/h2>\n\n<ul>\n  <li><strong>Noop<\/strong>: Minimale overhead op SSD\/NVMe en in VM's<\/li>\n  <li><strong>mq-deadline<\/strong>: Evenwichtige latentie en doorvoer voor servers<\/li>\n  <li><strong>BFQ<\/strong>: Eerlijkheid en snelle reactie bij multi-user<\/li>\n  <li><strong>blk-mq<\/strong>: Multi-queue-ontwerp voor moderne hardware<\/li>\n  <li><strong>Afstemmen<\/strong>: Tests per workload in plaats van vaste regels<\/li>\n<\/ul>\n\n<h2>Hoe de I\/O-planner in Linux-hosting werkt<\/h2>\n\n<p>Een Linux I\/O-scheduler rangschikt I\/O-verzoeken in wachtrijen, voert samenvoegingen uit en beslist over de levering aan het apparaat om <strong>Latency<\/strong> te verlagen en de doorvoer te verhogen. Moderne kernels maken gebruik van blk-mq, oftewel multi-queue, zodat meerdere CPU-kernen parallel I\/O kunnen starten. Dit past bij NVMe-SSD's, die veel wachtrijen en een hoge mate van parallelliteit bieden en zo wachtrijen verkorten. In hosting komen vaak brede gemengde belastingen samen: webservers leveren veel kleine reads, databases genereren sync-writes, back-ups genereren streams. De juiste scheduler vermindert congestie, houdt responstijden stabiel en beschermt de <strong>Server<\/strong>-Ervaring onder belasting.<\/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 in de praktijk: none vs. noop en kernel-standaardinstellingen<\/h2>\n\n<p>Sinds kernel 5.x is het multi-queue-ontwerp de standaardroute. Daarbij is <strong>geen<\/strong> het equivalent van \u201eNoop\u201c voor blk-mq, terwijl <strong>noop<\/strong> historisch gezien afkomstig is uit het single-queue-pad. Op NVMe-apparaten is meestal alleen <code>geen<\/code> beschikbaar; op SATA\/SAS ziet men vaak <code>mq-deadline<\/code>, optioneel <code>bfq<\/code> en afhankelijk van de distributie ook <code>kyber<\/code>. De standaardinstellingen vari\u00ebren: NVMe start doorgaans met <code>geen<\/code>, SCSI\/SATA vaak met <code>mq-deadline<\/code>. Ik controleer daarom altijd de beschikbare opties via <code>cat \/sys\/block\/\/queue\/scheduler<\/code> en beslis per apparaat. Waar alleen <code>geen<\/code> selecteerbaar is, is dat bewust zo gedaan \u2013 extra sortering levert daar praktisch geen meerwaarde op.<\/p>\n\n<h2>Noop in servergebruik: wanneer minimalisme wint<\/h2>\n\n<p>Noop voert vooral het samenvoegen van aangrenzende blokken uit, maar sorteert niet, wat de CPU-overhead extreem <strong>laag<\/strong> houdt. Op SSD's en NVMe nemen controllers en firmware de slimme volgorde over, zodat extra sortering in de kernel nauwelijks nut heeft. In VM's en containers plan ik vaak Noop in, omdat de hypervisor toch al overkoepelend plant. Op roterende schijven zie ik af van Noop, omdat het ontbreken van sortering daar de zoektijden verlengt. Wie de hardwarecontext veilig wil afbakenen, kijkt eerst naar het type geheugen \u2013 hier helpt een blik op <a href=\"https:\/\/webhosting.de\/nl\/nvme-ssd-hdd-webhosting-vergelijking-prestaties-kosten-tips-serverprofi\/\">NVMe, SSD en HDD<\/a>, voordat ik de planner <strong>vastleggen<\/strong>.<\/p>\n\n<h2>mq-deadline: deadlines, volgordes en duidelijke prioriteiten<\/h2>\n\n<p>mq-deadline geeft leesbewerkingen korte deadlines en laat schrijfbewerkingen iets langer wachten om <strong>Reactietijd<\/strong> merkbaar te beveiligen. De scheduler sorteert bovendien op blokadressen en verkort zo de zoektijden, wat vooral HDD's en RAID-verbindingen ten goede komt. In web- en databasehosts biedt mq-deadline een goede balans tussen latentie en doorvoer. Ik gebruik het graag wanneer workloads gemengd zijn en zowel lees- als schrijfbewerkingen permanent in de wachtrij staan. Voor de fijnafstemming controleer ik de verzoekdiepte, het writeback-gedrag en de controller-cache, zodat de deadline-logica consistent is. <strong>pakt<\/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: eerlijkheid en reactiesnelheid voor veel gelijktijdige gebruikers<\/h2>\n\n<p>BFQ verdeelt de bandbreedte proportioneel en wijst budgetten per proces toe, wat merkbaar is. <strong>beurs<\/strong> werkt wanneer veel gebruikers tegelijkertijd I\/O genereren. Interactieve taken zoals admin-shells, editors of API-calls blijven snel, ook al worden er op de achtergrond back-ups uitgevoerd. Op HDD's bereikt BFQ vaak een hoge effici\u00ebntie, omdat het gebruikmaakt van sequenti\u00eble fasen en korte idle-vensters slim inzet. Op zeer snelle SSD's ontstaat er een beetje extra werk, dat ik afweeg tegen de merkbare reactiesnelheid. Wie Cgroups en ioprio gebruikt, kan met BFQ duidelijke garanties geven en zo ergernis door luidruchtige buren voorkomen. <strong>Vermijd<\/strong>.<\/p>\n\n<h2>QoS in het dagelijks leven: ioprio, ionice en Cgroups v2 met BFQ<\/h2>\n\n<p>Voor schone <strong>Prioritering<\/strong> combineer ik BFQ met proces- en cgroup-regels. Op procesniveau stel ik met <code>ionice<\/code> Klassen en prioriteiten: <code>ionice -c1<\/code> (Realtime) voor latentie-kritische reads, <code>ionice -c2 -n7<\/code> (Best-Effort, laag) voor back-ups of index-runs, <code>ionice -c3<\/code> (Idle) voor alles wat alleen in rustperiodes moet draaien. In Cgroups v2 gebruik ik <code>io.gewicht<\/code> voor relatieve aandelen (bijv. 100 vs. 1000) en <code>io.max<\/code> voor harde limieten, bijvoorbeeld <code>echo \"259:0 rbps=50M wbps=20M\" &gt; \/sys\/fs\/cgroup\/\/io.max<\/code>. Met BFQ worden gewichten zeer nauwkeurig omgezet in bandbreedte-aandelen \u2013 ideaal voor shared hosting en containerhosts waarop <strong>Eerlijkheid<\/strong> belangrijker is dan maximale ruwkracht.<\/p>\n\n<h2>Praktijkvergelijking: welke keuze past bij de hardware?<\/h2>\n\n<p>De keuze hangt sterk af van het type geheugen en de wachtrijarchitectuur, dus ik controleer eerst <strong>Apparaat<\/strong> en controllers. SSD's en NVMe's profiteren meestal van Noop\/none, HDD's werken beter met mq-deadline of BFQ. In RAID-opstellingen, SAN's en allround hosts geef ik vaak de voorkeur aan mq-deadline, omdat deadline-logica en sortering goed samenwerken. Multi-useromgevingen met veel interactieve sessies hebben vaak baat bij BFQ. De volgende tabel geeft een overzicht van de sterke punten en zinvolle toepassingsgebieden. <strong>samen<\/strong>:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>planner<\/th>\n      <th>Hardware<\/th>\n      <th>Sterke punten<\/th>\n      <th>Zwakke punten<\/th>\n      <th>Hostingscenario's<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Noop\/none<\/td>\n      <td>SSD, NVMe, VM's<\/td>\n      <td>Minimale overhead, nette samenvoeging<\/td>\n      <td>Zonder sortering op HDD's nadelig<\/td>\n      <td>Flash-server, container, hypervisor-gestuurd<\/td>\n    <\/tr>\n    <tr>\n      <td>mq-deadline<\/td>\n      <td>HDD, RAID, allround-server<\/td>\n      <td>Strenge leesprioriteit, sortering, solide latentie<\/td>\n      <td>Meer logica dan Noop<\/td>\n      <td>Databases, web-backends, gemengde belastingen<\/td>\n    <\/tr>\n    <tr>\n      <td>BFQ<\/td>\n      <td>HDD, multi-user, desktop-achtige hosts<\/td>\n      <td>Eerlijkheid, reactievermogen, goede sequenties<\/td>\n      <td>Iets meer overhead op zeer snelle SSD's<\/td>\n      <td>Interactieve diensten, shared 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>Configuratie: planner controleren en permanent instellen<\/h2>\n\n<p>Eerst kijk ik welke planner actief is, bijvoorbeeld met <code>cat \/sys\/block\/sdX\/queue\/scheduler<\/code>, en noteer de <strong>Optie<\/strong> tussen vierkante haakjes. Om tijdelijk te wisselen, schrijf ik bijvoorbeeld <code>echo mq-deadline | sudo tee \/sys\/block\/sdX\/queue\/scheduler<\/code>. Voor permanente instellingen gebruik ik udev-regels of kernelparameters zoals <code>scsi_mod.use_blk_mq=1<\/code> en <code>mq-deadline<\/code> in de opdrachtregel. Bij NVMe-apparaten controleer ik paden onder <code>\/sys\/block\/nvme0n1\/queue\/<\/code> en stel de keuze per apparaat in. Belangrijk: ik documenteer wijzigingen, zodat onderhoud en rollback zonder giswerk mogelijk zijn. <strong>slagen<\/strong>.<\/p>\n\n<h2>Persistentie en automatisering tijdens het gebruik<\/h2>\n\n<p>In het dagelijks leven geef ik de voorkeur aan herhaalbaarheid boven automatisering. Drie manieren hebben hun waarde bewezen:<\/p>\n<ul>\n  <li><strong>udev-regels<\/strong>: Voorbeeld voor alle HDD's (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>, dan <code>udevadm control --reload-rules &amp;&amp; udevadm trigger<\/code>.<\/li>\n  <li><strong>systemd-tmpfiles<\/strong>: Voor specifieke apparaten definieer ik <code>\/etc\/tmpfiles.d\/blk.conf<\/code> met regels als <code>w \/sys\/block\/sdX\/queue\/scheduler - - - - mq-deadline<\/code>, die bij het opstarten schrijven.<\/li>\n  <li><strong>Configuratiebeheer<\/strong>: In Ansible\/Salt maak ik apparaatklassen (NVMe, HDD) aan en verdeel ik consistente standaardinstellingen, inclusief documentatie en rollback.<\/li>\n<\/ul>\n<p>Opmerking: <code>elevator=<\/code> als kernelparameter gold voor het oude single-queue-pad. In blk-mq bepaal ik de keuze <strong>per apparaat<\/strong>. Bij stacks (dm-crypt, LVM, MD) stel ik de standaardinstelling in op het top-apparaat, meer hierover verderop.<\/p>\n\n<h2>Workloads in hosting: patronen herkennen en correct handelen<\/h2>\n\n<p>Ik analyseer eerst de belasting: veel kleine reads duiden op webfrontends, sync-heavy writes op databases en log-pipelines, grote sequenti\u00eble streams op back-ups of <strong>Archief<\/strong>. Hulpmiddelen zoals <code>iostat<\/code>, <code>vmstat<\/code> en <code>blktrace<\/code> tonen wachtrijen, latenties en merge-effecten. Bij opvallende CPU-inactiviteit door I\/O verwijs ik naar <a href=\"https:\/\/webhosting.de\/nl\/io-wait-begrijpen-geheugenbottleneck-oplossen-optimalisatie\/\">I\/O-wacht begrijpen<\/a>, om knelpunten op een gestructureerde manier op te lossen. Daarna test ik 1-2 kandidaat-planners in identieke tijdvensters. Alleen meetresultaten zijn doorslaggevend, niet mijn intu\u00eftie of <strong>Mythen<\/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>Meetpraktijk verdiepen: reproduceerbare benchmarks<\/h2>\n\n<p>Voor betrouwbare beslissingen maak ik gebruik van gecontroleerde <strong>fio<\/strong>-Profielen en bevestig met echte applicatietests:<\/p>\n<ul>\n  <li><strong>Willekeurige lezingen<\/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>Willekeurige mix<\/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>Sequentieel<\/strong> (Back-up): <code>fio --name=seqw --rw=write --bs=1m --iodepth=128 --numjobs=2 --runtime=120 --time_based --direct=1<\/code><\/li>\n<\/ul>\n<p>Tegelijkertijd log ik in <code>iostat -x 1<\/code>, <code>pidstat -d 1<\/code> en noteer P95\/P99-latenties uit <code>fio<\/code>. Voor diepgaande diagnoses gebruik ik <code>blktrace<\/code> of eBPF-tools zoals <code>biolatency<\/code> . Belangrijk: ik meet op dezelfde tijdstippen van de dag, met dezelfde belastingvensters en dezelfde bestandsgroottes. Ik minimaliseer cache-effecten met <code>direct=1<\/code> en schone pre-condities (bijv. pre-fill op het volume).<\/p>\n\n<h2>Bestandssystemen en I\/O-planners: samenwerking is belangrijk<\/h2>\n\n<p>Het bestandssysteem be\u00efnvloedt de I\/O-kenmerken, dus ik controleer de journaalmodus, wachtrijdiepte en synchronisatiegedrag ervan zeer nauwkeurig. <strong>precies<\/strong>. EXT4 en XFS werken effici\u00ebnt met mq-deadline, terwijl ZFS veel zelf buffert en aggregeert. Op hosts met ZFS zie ik het scheduler-effect vaak minder, omdat ZFS de uitvoer al vormgeeft. Voor vergelijkingen gebruik ik identieke mount-opties en workloads. Wie opties afweegt, vindt in <a href=\"https:\/\/webhosting.de\/nl\/ext4-xfs-zfs-hosting-prestaties-vergelijking-opslag\/\">EXT4, XFS of ZFS<\/a> nuttige perspectieven op <strong>Opslag<\/strong>-Tuning.<\/p>\n\n<h2>Writeback, cache en barri\u00e8res: de vaak over het hoofd geziene helft<\/h2>\n\n<p>Schedulers kunnen alleen zo goed werken als het writeback-subsysteem toestaat. Daarom controleer ik altijd:<\/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> bepalen wanneer en hoe agressief de kernel schrijft. Voor databases verlaag ik vaak burst-pieken om P99 stabiel te houden.<\/li>\n  <li><strong>Barri\u00e8res\/Flush<\/strong>: Opties zoals EXT4 <code>barri\u00e8re<\/code> Ik beveilig alleen XFS-standaardflushes als hardware (bijv. BBWC) deze overneemt. \u201enobarrier\u201c zonder stroombeveiliging is <strong>riskant<\/strong>.<\/li>\n  <li><strong>Apparaat schrijfcache<\/strong>: Ik controleer de instellingen van het schrijfcachegeheugen van de controller, zodat <code>fsync<\/code> echt op het medium terechtkomt en niet alleen in de cache.<\/li>\n<\/ul>\n<p>Wie Writeback afvlakt, ontlast de planner \u2013 deadlines blijven betrouwbaar en BFQ hoeft minder te werken tegen plotselinge flush-golven.<\/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>Virtualisatie, containers en cloud: wie maakt er echt plannen?<\/h2>\n\n<p>In VM's regelt de hypervisor de fysieke I\/O-stroom, daarom kies ik in de gast vaak voor Noop\/none om dubbele <strong>logica<\/strong> te vermijden. Op de host zelf gebruik ik mq-deadline of BFQ, afhankelijk van het apparaat en de taak. Bij cloudvolumes (bijv. netwerkblokopslag) ligt een deel van de planning in de backend; daarom meet ik werkelijke latenties in plaats van te vertrouwen op aannames. Voor containerhosts met een sterk gemengde belasting biedt BFQ vaak betere interactiviteit. In homogene batchclusters met alleen flash wint Noop, omdat elke CPU-tijd telt en controllers effici\u00ebnt zijn. <strong>werk<\/strong>.<\/p>\n\n<h2>RAID, LVM, MD en Multipath: waar de scheduler ingrijpt<\/h2>\n\n<p>In gestapelde blokstapels zet ik de planner op de <strong>Topapparaat<\/strong> aan, want daar bevinden zich de relevante wachtrijen:<\/p>\n<ul>\n  <li><strong>LVM\/dm-crypt<\/strong>: Planner op <code>\/dev\/dm-*<\/code> respectievelijk <code>\/dev\/mapper\/<\/code> zetten. De fysieke PV's laat ik meestal op <code>geen<\/code>, zodat het samenvoegen\/sorteren niet dubbel gebeurt.<\/li>\n  <li><strong>MD-RAID<\/strong>: Op <code>\/dev\/mdX<\/code> beslissen; onderliggende <code>sdX<\/code> Apparaten blijven rustig aan staan <code>geen<\/code>. Hardware-RAID wordt behandeld als een enkel blokapparaat.<\/li>\n  <li><strong>Multipath<\/strong>: Op de multipath-mapper (<code>\/dev\/mapper\/mpatha<\/code>) vastleggen; pad-apparaten daaronder op <code>geen<\/code>.<\/li>\n<\/ul>\n<p>Belangrijk: ik scheid tests na <strong>zwembad<\/strong> en redundantie-niveau (RAID1\/10 vs. RAID5\/6). Pariteits-RAID's reageren gevoeliger op willekeurige schrijfbewerkingen; hier wint mq-deadline vaak door consistente leesdeadlines en geordende uitvoer.<\/p>\n\n<h2>Tuningstrategie\u00ebn: stap voor stap naar betrouwbare prestaties<\/h2>\n\n<p>Ik begin met een basismeting: huidige responstijden, doorvoer, 95\/99 percentiel en CPU-<strong>Belasting<\/strong>. Daarna verander ik slechts \u00e9\u00e9n factor, meestal de planner, en herhaal ik dezelfde belasting. Tools zoals <code>fio<\/code> helpen bij het controleren, maar ik bevestig elke hypothese met echte applicatietests. Voor databases zijn eigen benchmarks geschikt, die transacties en fsync-gedrag weergeven. Pas als de meting stabiel is, leg ik de keuze vast en documenteer ik het <strong>Waarom<\/strong>.<\/p>\n\n<h2>Wachtrijdiepte, readahead en CPU-affiniteit<\/h2>\n\n<p>Naast de planner hebben ook wachtrijparameters een grote invloed op de praktijk:<\/p>\n<ul>\n  <li><strong>Wachtrijdiepte<\/strong>: <code>\/sys\/block\/\/queue\/nr_requests<\/code> Beperkt het aantal lopende verzoeken per hardwarewachtrij. NVMe kan hoge diepte aan (hoge doorvoer), HDD's profiteren van matige diepte (stabielere latentie).<\/li>\n  <li><strong>Readahead<\/strong>: <code>\/sys\/block\/\/queue\/read_ahead_kb<\/code> respectievelijk <code>blockdev --getra\/setra<\/code>. Voor sequenti\u00eble workloads iets hoger, voor willekeurige workloads laag houden.<\/li>\n  <li><strong>rq_affinity<\/strong>Met <code>\/sys\/block\/\/queue\/rq_affinity<\/code> op 2 zorg ik ervoor dat I\/O-completion bij voorkeur op de genererende CPU-core terechtkomt \u2013 dat vermindert cross-CPU-kosten.<\/li>\n  <li><strong>roterend<\/strong>: Ik verifieer dat SSD's <code>rotational=0<\/code> melden, zodat de kernel geen HDD-heuristieken toepast.<\/li>\n  <li><strong>Samenvoegingen<\/strong>: <code>\/sys\/block\/\/queue\/nomerges<\/code> kan merges verminderen (2=uit). Voor NVMe-microlatentie soms zinvol, voor HDD's meestal nadelig.<\/li>\n  <li><strong>io_poll<\/strong> (NVMe): Polling kan latentie verminderen, maar vereist CPU. Ik activeer het specifiek bij <strong>Lage latentie<\/strong>-Vereisten.<\/li>\n<\/ul>\n\n<h2>Scheduler-tunables in detail<\/h2>\n\n<p>Afhankelijk van de planner zijn er zinvolle fijnafstemmingen beschikbaar:<\/p>\n<ul>\n  <li><strong>mq-deadline<\/strong>: <code>\/sys\/block\/\/queue\/iosched\/read_expire<\/code> (ms, typisch klein), <code>write_expire<\/code> (groter), <code>fifo_batch<\/code> (batchgrootte), <code>front_merges<\/code> (0\/1). Ik ben van mening dat <code>read_expire<\/code> kort, om P95-reads te beschermen, en pas aan <code>fifo_batch<\/code> afhankelijk van het apparaat.<\/li>\n  <li><strong>BFQ<\/strong>: <code>slice_idle<\/code> (Idle-tijd voor sequentiegebruik), <code>low_latency<\/code> (0\/1) voor responsieve interactiviteit. Met <code>bfq.gewicht<\/code> In Cgroups regel ik relatieve aandelen heel precies.<\/li>\n  <li><strong>none\/noop<\/strong>: Nauwelijks stelschroeven, maar de <strong>Omgeving<\/strong> (wachtrijdiepte, readahead) bepaalt de resultaten.<\/li>\n<\/ul>\n<p>Ik wijzig altijd slechts \u00e9\u00e9n parameter en noteer de wijziging nauwkeurig, zodat duidelijk blijft welk effect welke wijziging heeft gehad.<\/p>\n\n<h2>Veelvoorkomende valkuilen en hoe ik ze vermijd<\/h2>\n\n<p>Gemengde pools van HDD en SSD achter een RAID-controller vervalsen tests, daarom scheid ik metingen per <strong>Groep<\/strong>. Ik vergeet niet dat de scheduler per blokapparaat geldt \u2013 LVM-mapper en MD-apparaten beschouw ik apart. Persistentie glipt graag door: zonder udev-regel of kernelparameter staat na het herstarten weer de standaardinstelling. Cgroups en I\/O-prioriteiten blijven vaak ongebruikt, hoewel ze de eerlijkheid aanzienlijk vergroten. En ik controleer altijd de wachtrijdiepte, writeback en bestandssysteemopties, zodat de gekozen logica zijn potentieel <strong>toont<\/strong>.<\/p>\n\n<h2>Probleemoplossing: symptomen gericht lezen<\/h2>\n\n<p>Als de meetwaarden veranderen, interpreteer ik patronen en leid ik daar concrete stappen uit af:<\/p>\n<ul>\n  <li><strong>Hoge P99-latentie bij veel reads<\/strong>: Controleer of schrijfbewerkingen leesbewerkingen verdringen. Test met mq-deadline., <code>read_expire<\/code> verlagen, writeback afvlakken (<code>vm.dirty_*<\/code> aanpassen).<\/li>\n  <li><strong>100% util op HDD, lage doorvoersnelheid<\/strong>: Seeks domineren. Probeer BFQ of mq-deadline, verminder Readahead, matig de wachtrijdiepte.<\/li>\n  <li><strong>Goede doorvoersnelheden, maar UI hapert<\/strong>: Interactiviteit lijdt eronder. BFQ activeren, kritieke diensten via <code>ionice -c1<\/code> of Cgroup-gewichten geven de voorkeur.<\/li>\n  <li><strong>Sterke variatie afhankelijk van het tijdstip van de dag<\/strong>: Gedeelde bronnen. Isoleren met cgroups, scheduler per pool selecteren, back-ups verplaatsen naar off-peak.<\/li>\n  <li><strong>NVMe-time-outs in dmesg<\/strong>: Backend of firmware-onderwerp. <code>io_poll<\/code> Testmatig deactiveren, firmware\/driver controleren, padredundantie (multipath) verifi\u00ebren.<\/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 samengevat: duidelijke beslissingen voor dagelijkse hosting<\/h2>\n\n<p>Voor flashopslag en gasten kies ik vaak voor <strong>Noop<\/strong>, om overhead te besparen en controllers te laten werken. In allround servers met HDD of RAID levert mq-deadline betrouwbare latentie en hoge bruikbaarheid. Bij veel actieve gebruikers en interactieve belasting zorgt BFQ voor eerlijke verdeling en merkbare reactiesnelheid. Ik meet voor elke vastlegging met re\u00eble workloads en observeer de effecten op P95\/P99. Zo neem ik begrijpelijke beslissingen, houd ik systemen snel en stabiliseer ik de <strong>Server<\/strong>-Prestaties in de dagelijkse bedrijfsvoering.<\/p>","protected":false},"excerpt":{"rendered":"<p>I\/O Scheduler Linux uitgelegd: noop, mq-deadline &amp; BFQ voor optimale hosting. Tips voor het optimaliseren van opslag voor serverprestaties.<\/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":"1826","_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\/nl\/wp-json\/wp\/v2\/posts\/16149","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=16149"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/16149\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/16142"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=16149"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=16149"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=16149"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}