{"id":21042,"date":"2026-08-27T08:32:23","date_gmt":"2026-08-27T06:32:23","guid":{"rendered":"https:\/\/webhosting.de\/irq-balance-linux-konfigurieren-server\/"},"modified":"2026-08-27T08:32:23","modified_gmt":"2026-08-27T06:32:23","slug":"irq-balans-configureren-op-linux-server","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/irq-balance-linux-konfigurieren-server\/","title":{"rendered":"IRQ Balance onder Linux correct configureren: praktische handleiding"},"content":{"rendered":"<p>IRQ Balance regelt onder Linux de verdeling van hardware-interrupts over CPU-kernen en bepaalt daarmee of de netwerkbelasting gelijkmatig wordt verdeeld of dat bepaalde kernen worden afgeremd. Ik laat je zien hoe je irqbalance doelgericht kunt inzetten, wanneer ik overschakel naar handmatige IRQ-affiniteit en welke instellingen geschikt zijn voor servers met een hoge <strong>netwerkbelasting<\/strong> echt tellen.<\/p>\n\n<h2>Centrale punten<\/h2>\n<p>Voordat ik in detail treed, vat ik de belangrijkste beslissingen samen die mij in projecten met een hoge I\/O-belasting altijd goed van pas zijn gekomen. Ik vind het zinvol om de automatische verdeling via irqbalance als uitgangspunt te nemen, het effect te meten en selectief aanpassingen te doen. Bij deterministische workloads koppel ik afzonderlijke IRQ's handmatig aan bepaalde kernen en sluit ik de overige CPU's uit van de automatische verdeling. Ik houd al in een vroeg stadium rekening met NUMA-nabijheid, omdat dit de latentie verlaagt en de doorvoer waarborgt. Met duidelijke monitoring herken ik knelpunten sneller en los ik deze op zonder onnodige <strong>Risico's<\/strong>.<\/p>\n<p>Deze lijst laat zien waar ik bij de configuratie extra op let:<\/p>\n<ul>\n  <li><strong>Automatisch<\/strong> Eerst: irqbalance inschakelen, het effect meten<\/li>\n  <li><strong>affiniteit<\/strong> gericht: kritieke IRQ's vastzetten, jitter verminderen<\/li>\n  <li><strong>Verboden CPU's<\/strong>: Ruimte vrijhouden voor app-threads<\/li>\n  <li><strong>NUMA<\/strong> Let op: houd IRQ\u2019s dicht bij het geheugenknooppunt<\/li>\n  <li><strong>Controle<\/strong>: \/proc\/interrupts en latenties controleren<\/li>\n<\/ul>\n\n<h2>IRQ-basisprincipes in het kort uitgelegd<\/h2>\n<p>Een interruptverzoek (IRQ) is een signaal waarmee hardware taken aan de CPU overdraagt en daarmee een lopende taak onderbreekt. Als er te veel van deze signalen bij dezelfde kern binnenkomen, neemt de belasting daar toe en wordt de reactietijd traag, terwijl andere kernen onbenut blijven; dat is precies wat ik wil bereiken met <strong>Distributie<\/strong> vermijden. irqbalance verdeelt deze IRQ\u2019s dynamisch over meerdere kernen en beoordeelt met regelmatige tussenpozen de systeemstatus. Ik bekijk daarvoor eerst <code>\/proc\/onderbrekingen<\/code> en kijk in de kolommen hoeveel IRQ\u2019s er per CPU binnenkomen. Als bepaalde kolommen te groot worden, pas ik dit actief aan en verminder zo onnodige <strong>Hotspots<\/strong>.<\/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-irq-guide-4513.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Automatische verdeling met irqbalance<\/h2>\n<p>Op moderne distributies start ik met de service irqbalance, die standaard de IRQ-verdeling periodiek aanpast. Ik schakel deze service handmatig in met <code>systemctl enable --now irqbalance<\/code> en controleer ik de status voordat ik ingrijpender maatregelen neem; zo maak ik gebruik van de beschikbare <strong>Automatisch<\/strong>. De configuratiebestanden bevinden zich, afhankelijk van het systeem, in <code>\/etc\/sysconfig\/irqbalance<\/code> of <code>\/etc\/default\/irqbalance<\/code>, daar kan ik CPU's of IRQ's uitsluiten. De variabele is bijzonder nuttig <code>IRQBALANCE_BANNED_CPUS<\/code> als 64-bits masker om bepaalde kernen voor applicaties te reserveren. Wie zich verder wil verdiepen in praktijkvoorbeelden, vindt hier een beknopte inleiding tot de <a href=\"https:\/\/webhosting.de\/nl\/server-irq-balancing-netwerkprestatieoptimalisatie-datacenter\/\">Netwerkprestaties<\/a>, waarnaar ik in workshops vaak verwijs en die ik in projecten toepas.<\/p>\n\n<h2>IRQ-affiniteit handmatig veilig implementeren<\/h2>\n<p>Als workloads erg gevoelig zijn voor jitter of als bepaalde kernen uitsluitend vrij moeten blijven voor user-space-processen, stel ik de IRQ-affiniteit handmatig in. Hiervoor schrijf ik bitmaskers na <code>\/proc\/irq\/<em>IRQ-NUMMER<\/em>\/smp_affinity<\/code> en bepaal op welke kerns een interrupt mag worden uitgevoerd; dat maakt het mogelijk om te plannen <strong>Gedrag<\/strong>. Eerst bepaal ik de relevante IRQ-nummers met <code>grep<\/code> in <code>\/proc\/onderbrekingen<\/code>. Voor netwerkapparaten wijs ik RX\/TX-wachtrijen vaak toe aan kernen die dicht bij de app-threads liggen, terwijl ik andere kernen vrijhoud. Deze korte uitleg geeft een goed inzicht in deze aanpak <a href=\"https:\/\/webhosting.de\/nl\/server-irq-affiniteit-multicore-netwerk-optimalisatie-prestaties\/\">Gids voor IRQ-affiniteit<\/a>, die ik regelmatig als uitgangspunt gebruik.<\/p>\n<p>De volgende tabel toont veelgebruikte bitmaskers en wat ze betekenen. Ik gebruik deze voorbeelden om configuraties snel en foutloos in te stellen en het effect vervolgens te controleren met <code>\/proc\/onderbrekingen<\/code> naar <strong>verifi\u00ebren<\/strong>.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Doel<\/th>\n      <th>Voorbeeldmasker (hex)<\/th>\n      <th>kernen<\/th>\n      <th>Commentaar<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Alleen CPU0<\/td>\n      <td>0x1<\/td>\n      <td>0<\/td>\n      <td>Eenvoudige test, weinig <strong>verspreiding<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Alleen CPU1<\/td>\n      <td>0x2<\/td>\n      <td>1<\/td>\n      <td>Scheidt IRQ's van CPU0, verlaagt <strong>Interferentie<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>CPU0\u2013CPU1<\/td>\n      <td>0x3<\/td>\n      <td>0\u20131<\/td>\n      <td>Verdeeld over twee kernen, licht <strong>Hulp<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>CPU2\u2013CPU3<\/td>\n      <td>0xC<\/td>\n      <td>2-3<\/td>\n      <td>Handig als 0\u20131 voor app-threads <strong>gratis<\/strong> blijf<\/td>\n    <\/tr>\n    <tr>\n      <td>CPU0\u2013CPU3<\/td>\n      <td>0xF<\/td>\n      <td>0\u20133<\/td>\n      <td>Brede spreiding over 4 kernen, mengt <strong>Belasting<\/strong><\/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\/2026\/08\/IRQ_Linux_Konferenz_3235.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Meting: \/proc\/interrupts correct uitlezen<\/h2>\n<p>Ik open het bestand <code>\/proc\/onderbrekingen<\/code> en zie per rij een IRQ en per kolom de tellers per CPU; dat maakt onevenwichtigheden meteen duidelijk <strong>zichtbaar<\/strong>. Als een kolom aanzienlijk sneller groeit dan andere, concentreert de belasting zich daar. Vervolgens controleer ik welke driver hierbij betrokken is en of RSS\/RPS al wordt verdeeld. Daarnaast start ik irqbalance tijdelijk op de voorgrond met debug-uitvoer, om zijn beslissingen te begrijpen en verkeerde inschattingen te voorkomen. Na elke wijziging controleer ik de tellers opnieuw en meet ik de latentie onder belasting, zodat ik effecten kan aantonen en onnodige <strong>Risico's<\/strong> kan vermijden.<\/p>\n\n<h2>CPU-isolatie en verboden maskers<\/h2>\n<p>Ik stel <code>IRQBALANCE_BANNED_CPUS<\/code>, om bepaalde kernen consequent uit te sluiten van de automatische toewijzing; zo houd ik resources vrij voor app-threads. In nieuwere configuraties maak ik bovendien gebruik van <code>IRQBALANCE_BANNED_IRQS<\/code>, wanneer afzonderlijke apparaten zelfstandig op \u00e9\u00e9n kern moeten draaien; dat vermindert storingen voor gevoelige <strong>Werklasten<\/strong>. In scenario\u2019s met lage latentie schakel ik irqbalance doelbewust uit en wijs ik IRQ\u2019s statisch toe, zodat er geen herverdeling plaatsvindt die het proces verstoort. Wie de CPU-toewijzing bij interruptverwerking beter wil begrijpen, vindt nuttige achtergrondinformatie over de <a href=\"https:\/\/webhosting.de\/nl\/server-interruptverwerking-cpu-prestatieoptimalisatie-7342\/\">Afhandeling van interrupts<\/a> op servers. Belangrijk blijft: eerst meten, dan vaststellen en het effect opnieuw controleren, om verrassingen in de <strong>Operatie<\/strong> te vermijden.<\/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\/irq-balance-linux-guide-setup-3458.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NUMA-aspecten en nabijheid<\/h2>\n<p>Op NUMA-systemen zorg ik ervoor dat IRQ\u2019s zoveel mogelijk worden doorgestuurd naar de kernen van die NUMA-knoop waarin de betreffende gegevens in het geheugen zijn opgeslagen; dit vermindert de latentie en verhoogt <strong>Doorvoer<\/strong>. Ik combineer dit met CPU-affiniteit voor de applicatie, zodat threads en interrupts lokaal ten opzichte van elkaar worden uitgevoerd. irqbalance werkt goed op NUMA, maar indien nodig pas ik het aan met banned-maskers. Het is van cruciaal belang om de belasting niet over knooppunten te verspreiden als deze toch lokaal kan worden gehouden. Wie deze nabijheid handhaaft, profiteert van constante responstijden en spaart kostbare <strong>Cache<\/strong>-bronnen.<\/p>\n\n<h2>Netwerkintensief: RSS, RPS\/RFS en XPS<\/h2>\n<p>Voordat ik IRQ-maskers nauwkeurig afstem, controleer ik de NIC-functies zoals RSS en kernelmechanismen zoals RPS\/RFS en XPS; deze hebben een grote invloed op de verdeling van pakketten. RSS verdeelt wachtrij-interrupts al over meerdere kernen, terwijl RPS\/RFS de verwerking in de kernel en XPS de verzendpaden vormgeven; dit voorkomt onnodige <strong>Hotspots<\/strong>. Ik stem deze mechanismen af op mijn IRQ-strategie, zodat ze elkaar niet tegenwerken. Als de wachtrijen, de IRQ-affiniteiten en de app-affiniteit op elkaar zijn afgestemd, verloopt de netwerk-I\/O aanzienlijk soepeler. Daarna voer ik opnieuw metingen uit onder re\u00eble belasting, voordat ik verdere <strong>Stappen<\/strong> zet.<\/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\/irq_balance_linux_guide_7163.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>MSI-X, Multi-Queue en een overzichtelijke wachtrijindeling<\/h2>\n<p>Veel 10\u2013100G-NIC\u2019s maken gebruik van MSI-X en stellen per RX\/TX-wachtrij eigen interruptvectoren beschikbaar. Ik controleer dit eerst met <code>ethtool -l eth0<\/code> (aantal kanalen) en <code>\/proc\/onderbrekingen<\/code>, hoeveel wachtrijen er werkelijk actief zijn en hoe ze heten (bijv. <code>eth0-TxRx-0<\/code>, <code>eth0-TxRx-1<\/code>). Het doel is om het aantal wachtrijen af te stemmen op het aantal gebruikte kernen per NUMA-knooppunt en deze deterministisch vast te zetten. Met <code>ethtool -L eth0 combined N<\/code> stel ik het aantal wachtrijen in; daarna rangschik ik de resulterende IRQ\u2019s via <code>smp_affinity<\/code> geschikte kernen. Ik zorg ervoor dat RX\/TX-paren van dezelfde wachtrij op dezelfde kern of in ieder geval op dezelfde socket worden geplaatst, zodat <strong>Cache-locatie<\/strong> van toepassing is. Belangrijk: wijzigingen in het aantal wachtrijen en de affiniteit controleer ik direct in <code>\/proc\/onderbrekingen<\/code> en met een korte belastingstest (pps\/doorvoersnelheid), voordat ik verder ga met optimaliseren.<\/p>\n\n<h2>Interrupt-coalescentie en NAPI-budget<\/h2>\n<p>Vooral bij hoge pakketfrequenties be\u00efnvloeden de coalescentiewaarden de effectiviteit van mijn IRQ-strategie. Met <code>ethtool -c eth0<\/code> zie ik of <code>rx-usecs<\/code> en <code>rx-monturen<\/code> zijn ingesteld. Meer coalescentie vermindert het aantal IRQ\u2019s per seconde en bespaart CPU-vermogen, maar verhoogt de latentie en jitter. Ik pas de instellingen voorzichtig aan: kleine stapjes, telkens meten (p95\/p99-latentie en CPU-belasting). Aan de zendzijde heeft dit <code>tx-usecs<\/code> analoog. Daarnaast pas ik het NAPI-gedrag aan via <code>net.core.netdev_budget<\/code> en <code>net.core.netdev_budget_usecs<\/code>, wanneer <strong>NET_RX<\/strong> in SoftIRQ's begint op te stapelen. Als het aantal drops toeneemt in <code>\/proc\/net\/softnet_stat<\/code>, verhoog ik bij wijze van test het budget of verdeel ik de RX-wachtrijen consequenter; als de systeemlatentie te hoog wordt, schroef ik het weer terug. Ik houd rekening met GRO\/LRO en TSO\/GSO in onderlinge samenhang: overmatige aggregatie verlaagt de IRQ-belasting, maar kan latentiepieken veroorzaken \u2013 ik stem deze af op het applicatieprofiel.<\/p>\n\n<h2>SoftIRQ's transparant lezen<\/h2>\n<p>Naast HardIRQ's bepaal ik ook de belasting van de SoftIRQ's. Met <code>cat \/proc\/softirqs<\/code> Ik observeer <strong>NET_RX<\/strong> en <strong>NET_TX<\/strong> per CPU; als bepaalde kolommen de overhand hebben, komt er te veel werk terecht in de ksoftirqd-threads. Een <code>top -H<\/code> laat me snel zien welke <code>ksoftirqd\/N<\/code> Kernen belasten. Ik meet dieper met <code>perf top<\/code> of korte <code>perf record<\/code> Uitvoeren om hotspots in het stuurprogramma of de stackverwerking te identificeren. Als ksoftirqd-threads actief worden (in plaats van directe verwerking in de IRQ-context), neemt de latentie vaak aanzienlijk toe; ik reageer hierop met een betere wachtrijverdeling, een groter NAPI-budget of gerichte CPU-pinning van de betreffende ksoftirqd-threads via <code>taskset -pc<\/code>. Belangrijk: ik leg deze aanpassingen vast, omdat ze subtiele gevolgen hebben en ik in geval van twijfel snel een rollback nodig heb.<\/p>\n\n<h2>SMT\/Hyper-Threading en topologie op de juiste manier gebruiken<\/h2>\n<p>Met SMT ingeschakeld deel ik \u00e9\u00e9n fysieke kern met twee logische CPU\u2019s. Ik controleer de sibling-relaties via <code>lscpu -e<\/code> en <code>\/sys\/devices\/system\/cpu\/cpuX\/topology\/thread_siblings_list<\/code>. Voor latentiegevoelige paden vermijd ik het om de app-thread en de bijbehorende IRQ op dezelfde fysieke kern (verschillende SMT-threads) te plaatsen; ze concurreren namelijk om uitvoereenheden en caches. Ik geef de voorkeur aan combinaties waarbij bijvoorbeeld een app-thread op CPU2 draait en de bijbehorende RX-wachtrij op CPU3 (andere fysieke kern, hetzelfde NUMA-knooppunt). Als SMT de consistentie verstoort, plan ik in plaats daarvan met minder, maar exclusieve fysieke kernen en bespaar ik mezelf onrustige <strong>Interferenties<\/strong>.<\/p>\n\n<h2>Virtualisatie: KVM, vhost en SR-IOV<\/h2>\n<p>In gevirtualiseerde omgevingen beschouw ik de host en de gast als afzonderlijke entiteiten. Op de host verdeel ik fysieke NIC-IRQ\u2019s netjes over de kernen van het betreffende NUMA-knooppunt. Als de gast virtio-net gebruikt, ontstaan er extra IRQ\u2019s voor vhost-threads; ik herken ze in <code>\/proc\/onderbrekingen<\/code> en koppel vhost-workers consistent aan de wachtrijen van de fysieke NIC. Op gastniveau stel ik ook RSS\/XPS- en IRQ-affiniteiten in, voor zover het virtio-stuurprogramma meerdere wachtrijen biedt. Bij SR-IOV loont het de moeite om elke gast een of meer VF\u2019s met eigen MSI-X-vectoren toe te wijzen en deze in de gast te pinnen; de isolatie verbetert de latentie en voorspelbaarheid. Ik houd me aan een duidelijk schema: vCPU\u2019s van de gast op speciale pCPU\u2019s, bijbehorende IRQ\u2019s op nabijgelegen kernen, en de emulator-\/vhost-threads niet vermengen met rekenintensieve app-threads \u2013 zo blijft het datapad <strong>planbaar<\/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\/2026\/08\/irq_balance_linux_guide_5421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>CPU-frequentie, C-states en NOHZ-tuning<\/h2>\n<p>IRQ-latenties hebben eronder te lijden wanneer kernen in diepe C-toestanden terechtkomen of agressief klokken. Voor gevoelige workloads stel ik de CPU-governor in op <code>prestatie<\/code> (<code>cpupower frequency\u2011set -g performance<\/code>) en beperk ik diepe C-toestanden via opstart- of stuurprogramma-opties om de opstarttijden te beperken. Op zwaar belaste servers heeft dit vaak een positiever effect dan welke fijnafstemming van affiniteiten dan ook. Bij zeer strenge latentieprofielen voeg ik toe <code>nohz_full=<\/code> en <code>rcu_nocbs=<\/code> voor ge\u00efsoleerde kernen, zodat de tick-timer en RCU-callbacks elkaar niet verstoren; de housekeeping-CPU\u2019s definieer ik bewust afzonderlijk. Deze aanpassingen test ik echter apart, omdat ze neveneffecten kunnen hebben op de planning en het energieverbruik. Het blijft cruciaal om de meetwaarden v\u00f3\u00f3r en na de wijziging zorgvuldig te vergelijken, anders loop ik het risico dat ik bij <strong>Optimalisaties<\/strong> in het donker.<\/p>\n\n<h2>Systemd, cgroups en app-isolatie<\/h2>\n<p>Naast IRQ-pinning scheid ik app-threads met Cgroups en systemd-affinity. Via <code>CPUAffiniteit=<\/code> In Unit-bestanden en de CPU-controllers (cgroup v2) wijs ik diensten vaste cores toe. Zo voorkom ik dat threads door de scheduler worden verplaatst naar de CPU\u2019s die ik voor IRQ\u2019s heb gereserveerd. In containeromgevingen stel ik <code>cpuset.cpus<\/code> en controleer <code>cpuset.cpus.effective<\/code>, zodat toezeggingen over middelen ook daadwerkelijk worden nagekomen. Belangrijk: <code>IRQBALANCE_BANNED_CPUS<\/code> stuurt alleen aan waar irqbalance niet verdeelt; kernel-threads zoals ksoftirqd blijven de scheduler volgen. Voor strikte isolatie heb ik dus een combinatie nodig van IRQ-affiniteiten, CPU-affiniteit van de diensten en eventueel ge\u00efsoleerde kernels. Zo blijven het gegevenspad en de toepassing duidelijk gescheiden en de <strong>Belasting<\/strong> mengt zich niet op ongecontroleerde wijze.<\/p>\n\n<h2>Veelvoorkomende fouten en oplossingen<\/h2>\n<p>Ik schakel irqbalance nooit zomaar uit zonder de belastingprofielen te kennen; anders hopen de IRQ\u2019s zich al snel op een paar kernen op. Het is eveneens ongewenst om alle kernen voor alle IRQ\u2019s open te stellen, hoewel gevoelige threads exclusief <strong>Bronnen<\/strong> nodig hebben. Nog een fout: wijzigingen niet afzonderlijk testen en de effecten niet meten; zo blijft het onduidelijk wat daadwerkelijk helpt. Ik houd ook rekening met Hyper-Threading-paren: de app-thread en de bijbehorende IRQ kunnen beter niet dezelfde fysieke kern delen. Ik documenteer elke stap en maak terugzetpunten, zodat ik bij problemen snel terug kan naar de laatste <strong>goed<\/strong> Terug naar de configuratie.<\/p>\n\n<h2>Praktische checklist voor servers<\/h2>\n<p>Ik begin altijd met een uitgangssituatie: irqbalance ingeschakeld, de systeembelasting vaststellen, \/proc\/interrupts in de gaten houden en de latenties meten; pas daarna pas ik de instellingen aan. In de tweede stap sluit ik af met <code>IRQBALANCE_BANNED_CPUS<\/code> selecteer ik de kernen die voor app-threads gereserveerd moeten blijven; zo voorkom ik onnodige IRQ-onderbrekingen. Vervolgens pin ik kritieke IRQ's via <code>smp_affinity<\/code> op een klein aantal, zorgvuldig gekozen kernen en zorg ervoor dat de NUMA-afstand binnen de grenzen blijft. Vervolgens controleer ik RSS\/RPS\/RFS en XPS, evenals de offloading-opties van de NIC, om de werklast op een zinvolle manier te verdelen. Tot slot test ik onder productielast, vergelijk ik de statistieken en behoud ik alleen die wijzigingen waarvan aantoonbaar is dat ze <strong>werk<\/strong>.<\/p>\n\n<h2>Configuratiebestanden en systemd-opdrachten<\/h2>\n<p>Ik activeer de dienst met <code>systemctl enable --now irqbalance<\/code> en controleer met <code>systemctl status irqbalans<\/code> de looptijd; zo stel ik de <strong>Service<\/strong> zeker klaar. In <code>\/etc\/sysconfig\/irqbalance<\/code> of <code>\/etc\/default\/irqbalance<\/code> ik zet <code>IRQBALANCE_BANNED_CPUS<\/code> en optioneel <code>IRQBALANCE_BANNED_IRQS<\/code>. Wijzigingen neem ik over met <code>systemctl restart irqbalance<\/code> en houd tegelijkertijd de tellers in de gaten in <code>\/proc\/onderbrekingen<\/code>. Voor tests gebruik ik de foreground-modus van irqbalance om beslissingen in realtime te volgen. Pas als ik het gedrag begrijp, neem ik de aanpassingen definitief op in het <strong>Configuratie<\/strong>.<\/p>\n\n<h2>Wanneer ik irqbalance uitschakel<\/h2>\n<p>In realtime-opstellingen of bij toepassingen die uiterst gevoelig zijn voor latentie, stop ik `irqbalance` en wijs ik IRQ\u2019s statisch toe, zodat er geen herverdeling plaatsvindt die storingen veroorzaakt. Ik isoleer de kernen voor deze workloads en laat verkeers-IRQ\u2019s bewust op andere kernen draaien; zo blijven applicatiethreads <strong>planbaar<\/strong>. Ook bij strikt gescheiden tenant-omgevingen is deze aanpak de moeite waard, omdat ik zo interferenties tussen VM\u2019s of containers verminder. Als er stuurprogramma\u2019s zijn die minder goed werken met de automatische instelling, sluit ik hun IRQ\u2019s uit via een verbodenlijst. Zodra de belastingpatronen weer variabeler worden, activeer ik irqbalance opnieuw en controleer ik het effect met nieuwe <strong>Gemeten waarden<\/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\/2026\/08\/linux-irq-balance-setup-1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kort samengevat<\/h2>\n<p>Ik begin met irqbalance, meet het effect en pas het selectief aan, in plaats van overal blindelings in te grijpen; zo behoud ik het overzicht over het systeem en <strong>Transparantie<\/strong>. Voor gevoelige workloads wijs ik geschikte IRQ\u2019s toe, isoleer ik kerns voor applicaties en houd ik rekening met NUMA-nabijheid. Met banned-maskers bepaal ik waar irqbalance mag werken en voorkom ik ongewenste verschuivingen. Ik controleer regelmatig <code>\/proc\/onderbrekingen<\/code>, latentie en doorvoersnelheid, zodat wijzigingen op een betrouwbare manier worden onderbouwd. Wie op deze manier te werk gaat, benut het potentieel van IRQ Balance ten volle en houdt servers onder netwerkbelasting merkbaar <strong>reactief<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>irqbalance in Linux correct instellen: zo verdeelt u interrupts effici\u00ebnt op Linux-servers en verbetert u de prestaties.<\/p>","protected":false},"author":1,"featured_media":21035,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21042","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":"150","_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":"IRQ Balance","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":"21035","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21042","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=21042"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21042\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/21035"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=21042"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=21042"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=21042"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}