{"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":"konfigurere-irq-balance-pa-linux-server","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/irq-balance-linux-konfigurieren-server\/","title":{"rendered":"S\u00e5dan konfigureres IRQ Balance korrekt under Linux: En praktisk vejledning"},"content":{"rendered":"<p>IRQ Balance styrer under Linux fordelingen af hardware-interrupts p\u00e5 CPU-kerner og afg\u00f8r dermed, om netv\u00e6rksbelastningen fordeles j\u00e6vnt, eller om enkelte kerner bliver overbelastet. Jeg viser dig, hvordan du anvender irqbalance m\u00e5lrettet, hvorn\u00e5r jeg skifter til manuel IRQ-affinitet, og hvilke indstillinger der er optimale p\u00e5 servere med h\u00f8j <strong>netv\u00e6rksbelastning<\/strong> virkelig t\u00e6ller.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<p>Inden jeg g\u00e5r i detaljer, vil jeg sammenfatte de vigtigste beslutninger, der p\u00e5lideligt har hjulpet mig i projekter med h\u00f8j I\/O-belastning. Jeg anser den automatiske fordeling via irqbalance for at v\u00e6re et fornuftigt udgangspunkt, m\u00e5ler effekten og foretager selektive justeringer. Ved deterministiske arbejdsbelastninger tildeler jeg enkelte IRQ\u2019er manuelt til bestemte kerner og udelukker de \u00f8vrige CPU\u2019er fra den automatiske fordeling. Jeg tager h\u00f8jde for NUMA-n\u00e6rhed p\u00e5 et tidligt tidspunkt, da det reducerer latenstiden og sikrer genneml\u00f8bshastigheden. Med en tydelig overv\u00e5gning opdager jeg flaskehalse hurtigere og regulerer dem uden un\u00f8dvendige <strong>Risici<\/strong>.<\/p>\n<p>Denne liste viser dig, hvad jeg l\u00e6gger s\u00e6rlig v\u00e6gt p\u00e5 ved konfigurationen:<\/p>\n<ul>\n  <li><strong>Automatisk<\/strong> F\u00f8rst: Aktiver irqbalance, m\u00e5l effekten<\/li>\n  <li><strong>affinitet<\/strong> m\u00e5lrettet: fastl\u00e5se kritiske IRQ\u2019er, reducere jitter<\/li>\n  <li><strong>Forbudte CPU'er<\/strong>: Hold plads til kerner til app-tr\u00e5de<\/li>\n  <li><strong>NUMA<\/strong> Bem\u00e6rk: Hold IRQ\u2019er t\u00e6t p\u00e5 hukommelsesknudepunkterne<\/li>\n  <li><strong>Overv\u00e5gning<\/strong>: Kontroller \/proc\/interrupts og ventetiderne<\/li>\n<\/ul>\n\n<h2>IRQ-grundbegreber kort forklaret<\/h2>\n<p>En interrupt-anmodning (IRQ) er et signal, hvorved hardware overdrager arbejde til CPU\u2019en og dermed afbryder en igangv\u00e6rende opgave. Hvis der kommer for mange af disse signaler til den samme kerne, stiger belastningen der, og responstiden bliver langsom, mens andre kerner forbliver uudnyttede; det er netop det, jeg vil med <strong>Distribution<\/strong> undg\u00e5. irqbalance fordeler disse IRQ\u2019er dynamisk p\u00e5 flere kerner og vurderer systemtilstanden med j\u00e6vne mellemrum. Jeg ser f\u00f8rst p\u00e5 <code>\/proc\/afbrydelser<\/code> og se i kolonnerne, hvor mange IRQ\u2019er der kommer pr. CPU. Hvis enkelte kolonner bliver for store, justerer jeg aktivt og reducerer dermed un\u00f8dvendige <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>Automatisk fordeling med irqbalance<\/h2>\n<p>P\u00e5 moderne distributioner starter jeg med tjenesten irqbalance, som som standard j\u00e6vnligt justerer IRQ-fordelingen. Jeg aktiverer den med <code>systemctl enable --now irqbalance<\/code> og tjekker status, f\u00f8r jeg g\u00e5r mere i dybden; p\u00e5 den m\u00e5de udnytter jeg det eksisterende <strong>Automatisk<\/strong>. Konfigurationsfilerne findes, afh\u00e6ngigt af systemet, i <code>\/etc\/sysconfig\/irqbalance<\/code> eller <code>\/etc\/default\/irqbalance<\/code>, der kan jeg udelukke CPU\u2019er eller IRQ\u2019er. Variablen er s\u00e6rligt nyttig <code>IRQBALANCE_BANNED_CPUS<\/code> som en 64-bit-maske til at reservere bestemte kerner til applikationer. Hvis man \u00f8nsker at dykke dybere ned i praktiske eksempler, finder man her en kortfattet introduktion til <a href=\"https:\/\/webhosting.de\/da\/server-irq-balancering-optimering-af-netvaerkspraestation-datacenter\/\">Netv\u00e6rksydelse<\/a>, som jeg ofte henviser til i workshops og anvender i projekter.<\/p>\n\n<h2>Sikker implementering af manuel IRQ-affinitet<\/h2>\n<p>Hvis arbejdsbelastninger er meget f\u00f8lsomme over for jitter, eller hvis bestemte kerner skal holdes frie udelukkende til brugerrumsprocesser, indstiller jeg IRQ-affinitet manuelt. Til det form\u00e5l skriver jeg bitmasker efter <code>\/proc\/irq\/<em>IRQ-NUMMER<\/em>\/smp_affinity<\/code> og fastl\u00e6gger, p\u00e5 hvilke kerner en interrupt m\u00e5 k\u00f8re; det skaber planl\u00e6gningssikkerhed <strong>Adf\u00e6rd<\/strong>. F\u00f8rst finder jeg de relevante IRQ-numre ved hj\u00e6lp af <code>grep<\/code> p\u00e5 <code>\/proc\/afbrydelser<\/code>. For netv\u00e6rksenheder tildeler jeg ofte RX\/TX-k\u00f8er til kerner, der ligger t\u00e6t p\u00e5 app-tr\u00e5dene, mens jeg holder andre kerner fri. Denne korte artikel giver en god baggrund for denne fremgangsm\u00e5de <a href=\"https:\/\/webhosting.de\/da\/server-irq-affinitet-multicore-netvaerksoptimering-ydelse\/\">Vejledning i IRQ-affinitet<\/a>, som jeg regelm\u00e6ssigt bruger som udgangspunkt.<\/p>\n<p>Den f\u00f8lgende tabel viser almindelige bitmasker og deres betydning. Jeg bruger disse eksempler til hurtigt og fejlfrit at indstille konfigurationer og derefter kontrollere effekten med <code>\/proc\/afbrydelser<\/code> til <strong>verificere<\/strong>.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>M\u00e5l<\/th>\n      <th>Eksempel p\u00e5 maske (hex)<\/th>\n      <th>Kerner<\/th>\n      <th>Kommentar<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Kun CPU0<\/td>\n      <td>0x1<\/td>\n      <td>0<\/td>\n      <td>Enkel test, lav <strong>spredning<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Kun CPU1<\/td>\n      <td>0x2<\/td>\n      <td>1<\/td>\n      <td>Adskiller IRQ\u2019er fra CPU0, s\u00e6nker <strong>Interferens<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>CPU0\u2013CPU1<\/td>\n      <td>0x3<\/td>\n      <td>0\u20131<\/td>\n      <td>Fordelt p\u00e5 to kerner, let <strong>Aflastning<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>CPU2\u2013CPU3<\/td>\n      <td>0xC<\/td>\n      <td>2-3<\/td>\n      <td>Nyttigt, n\u00e5r 0\u20131 g\u00e6lder for app-tr\u00e5de <strong>gratis<\/strong> ophold<\/td>\n    <\/tr>\n    <tr>\n      <td>CPU0\u2013CPU3<\/td>\n      <td>0xF<\/td>\n      <td>0\u20133<\/td>\n      <td>Bred spredning over 4 kerner, blander <strong>Belastning<\/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>M\u00e5ling: Korrekt afl\u00e6sning af \/proc\/interrupts<\/h2>\n<p>Jeg \u00e5bner filen <code>\/proc\/afbrydelser<\/code> og ser en IRQ pr. r\u00e6kke samt t\u00e6llerne pr. CPU pr. kolonne; det afsl\u00f8rer straks ubalancer <strong>synlig<\/strong>. Hvis en kolonne vokser markant hurtigere end de andre, koncentreres belastningen der. S\u00e5 unders\u00f8ger jeg, hvilken driver der er involveret, og om RSS\/RPS allerede fordeler belastningen. Derudover starter jeg midlertidigt irqbalance i forgrunden med debug-udskrift for at forst\u00e5 dens beslutninger og undg\u00e5 fejlvurderinger. Efter hver \u00e6ndring kontrollerer jeg t\u00e6llerne igen og m\u00e5ler latenstiden under belastning, s\u00e5 jeg kan dokumentere effekterne og undg\u00e5 un\u00f8dvendige <strong>Risici<\/strong> kan undg\u00e5.<\/p>\n\n<h2>CPU-isolering og forbudte masker<\/h2>\n<p>Jeg s\u00e6tter <code>IRQBALANCE_BANNED_CPUS<\/code>, for konsekvent at udelukke bestemte kerner fra den automatiske fordeling; p\u00e5 den m\u00e5de holder jeg ressourcer fri til app-tr\u00e5de. I nyere ops\u00e6tninger bruger jeg desuden <code>IRQBALANCE_BANNED_IRQS<\/code>, hvis enkelte enheder skal k\u00f8re uafh\u00e6ngigt p\u00e5 en kerne; det mindsker forstyrrelser for f\u00f8lsomme <strong>Arbejdsbyrder<\/strong>. I scenarier med lav latenstid deaktiverer jeg m\u00e5lrettet irqbalance og tildeler IRQ\u2019er statisk, s\u00e5 der ikke sker nogen omfordeling, der forstyrrer. Hvis man \u00f8nsker at forst\u00e5 CPU-tildelingen af interrupt-h\u00e5ndtering bedre, kan man finde nyttige baggrundsoplysninger om <a href=\"https:\/\/webhosting.de\/da\/optimering-af-server-interrupt-handtering-af-cpu-ydelse-7342\/\">H\u00e5ndtering af afbrydelser<\/a> p\u00e5 servere. Det vigtige er stadig: f\u00f8rst m\u00e5le, derefter fastl\u00e6gge og igen kontrollere effekten for at undg\u00e5 overraskelser i <strong>Betjening<\/strong> for at undg\u00e5.<\/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-aspekter og n\u00e6rhed<\/h2>\n<p>P\u00e5 NUMA-systemer s\u00f8rger jeg for s\u00e5 vidt muligt at dirigere IRQ\u2019er til kerner p\u00e5 den NUMA-node, hvor de p\u00e5g\u00e6ldende data ligger i hukommelsen; det mindsker latenstiden og \u00f8ger <strong>Gennemstr\u00f8mning<\/strong>. Jeg kombinerer dette med CPU-affinitet for applikationen, s\u00e5 tr\u00e5de og interrupts k\u00f8rer lokalt i forhold til hinanden. irqbalance fungerer godt p\u00e5 NUMA, men jeg justerer efter behov ved hj\u00e6lp af banned-masker. Det er afg\u00f8rende ikke at sprede belastningen p\u00e5 tv\u00e6rs af noder, n\u00e5r den alligevel kan holdes lokalt. Hvis man opretholder denne n\u00e6rhed, opn\u00e5r man konstante responstider og sk\u00e5ner v\u00e6rdifulde <strong>Cache<\/strong>-Ressourcer.<\/p>\n\n<h2>Netv\u00e6rksintensivt kursus: RSS, RPS\/RFS og XPS<\/h2>\n<p>Inden jeg finjusterer IRQ-maskerne, tjekker jeg NIC-funktioner som RSS samt kerne-mekanismer som RPS\/RFS og XPS; de har stor indflydelse p\u00e5 fordelingen af pakker. RSS fordeler k\u00f8-interrupts allerede p\u00e5 flere kerner, mens RPS\/RFS styrer behandlingen i kernen og XPS former sendestierne; dette undg\u00e5r un\u00f8dvendige <strong>Hotspots<\/strong>. Jeg afstemmer disse mekanismer med min IRQ-strategi, s\u00e5 de ikke modarbejder hinanden. Hvis k\u00f8erne, IRQ-affinitetene og app-affiniteten stemmer overens, k\u00f8rer netv\u00e6rks-I\/O betydeligt mere smidigt. Derefter m\u00e5ler jeg igen under reel belastning, f\u00f8r jeg forts\u00e6tter med yderligere <strong>Trin<\/strong> s\u00e6t.<\/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\u2011X, Multi\u2011Queue og et overskueligt k\u00f8-layout<\/h2>\n<p>Mange 10\u2013100G-NIC\u2019er bruger MSI-X og stiller egne interrupt-vektorer til r\u00e5dighed for hver RX\/TX-k\u00f8. Jeg tjekker f\u00f8rst med <code>ethtool -l eth0<\/code> (antal kanaler) og <code>\/proc\/afbrydelser<\/code>, hvor mange k\u00f8er der rent faktisk er aktive, og hvad de hedder (f.eks. <code>eth0-TxRx-0<\/code>, <code>eth0-TxRx-1<\/code>). M\u00e5let er at tilpasse antallet af k\u00f8er til antallet af anvendte kerner pr. NUMA-node og fastl\u00e5se disse p\u00e5 en deterministisk m\u00e5de. Med <code>ethtool -L eth0 combined N<\/code> indstiller jeg antallet af k\u00f8er; derefter sorterer jeg de genererede IRQ\u2019er ved hj\u00e6lp af <code>smp_affinity<\/code> passende kerner. Jeg s\u00f8rger for, at RX\/TX-par fra samme k\u00f8 placeres p\u00e5 samme kerne eller i det mindste samme socket, s\u00e5 <strong>Cache-placering<\/strong> g\u00e6lder. Vigtigt: \u00c6ndringer i k\u00f8-tal og affinitet tjekker jeg direkte i <code>\/proc\/afbrydelser<\/code> og med en kort belastningstest (pps\/throughput), inden jeg forts\u00e6tter med at optimere.<\/p>\n\n<h2>Interrupt-koalescens og NAPI-budget<\/h2>\n<p>Is\u00e6r ved h\u00f8je pakkefrekvenser p\u00e5virker koalescensv\u00e6rdierne effektiviteten af min IRQ-strategi. Med <code>ethtool -c eth0<\/code> kan jeg se, om <code>rx-usecs<\/code> og <code>rx-rammer<\/code> er indstillet. Mere koalescens reducerer antallet af IRQ\u2019er pr. sekund og sparer CPU-ressourcer, men \u00f8ger latenstiden og jitteren. Jeg justerer forsigtigt: sm\u00e5 skridt, hvor jeg hver gang m\u00e5ler (p95\/p99-latenstid og CPU-belastning). P\u00e5 sendersiden virker <code>tx-usecs<\/code> analogt. Derudover skalerer jeg NAPI-adf\u00e6rden via <code>net.core.netdev_budget<\/code> og <code>net.core.netdev_budget_usecs<\/code>, n\u00e5r <strong>NET_RX<\/strong> begynder at hober sig op i SoftIRQ\u2019erne. Hvis antallet af drops stiger i <code>\/proc\/net\/softnet_stat<\/code>, \u00f8ger jeg budgettet som et fors\u00f8g eller fordeler RX-k\u00f8erne mere konsekvent; hvis systemforsinkelsen bliver for stor, skruer jeg ned igen. Jeg tager h\u00f8jde for GRO\/LRO og TSO\/GSO i samspil: Overdreven aggregering s\u00e6nker IRQ-belastningen, men kan skabe latenstop \u2013 jeg afbalancerer dem med applikationsprofilen.<\/p>\n\n<h2>Transparent afl\u00e6sning af SoftIRQ'er<\/h2>\n<p>Ud over HardIRQ\u2019er bestemmer jeg belastningen i SoftIRQ\u2019er. Med <code>cat \/proc\/softirqs<\/code> Jeg observerer <strong>NET_RX<\/strong> og <strong>NET_TX<\/strong> pr. CPU; hvis enkelte kolonner dominerer, ender for meget arbejde der i ksoftirqd-tr\u00e5de. En <code>top -H<\/code> vis mig hurtigt, hvilke <code>ksoftirqd\/N<\/code> Kerner belaster. Jeg m\u00e5ler dybere med <code>perf top<\/code> eller korte <code>perf-rekord<\/code> K\u00f8rer for at identificere hotspots i driveren eller i stakbehandlingen. Hvis ksoftirqd-tr\u00e5de bliver aktive (i stedet for direkte behandling i IRQ-konteksten), stiger latenstiden ofte markant; jeg reagerer med bedre k\u00f8fordeling, st\u00f8rre NAPI-budget eller m\u00e5lrettet CPU-pinning af de ber\u00f8rte ksoftirqd-tr\u00e5de via <code>taskset -pc<\/code>. Vigtigt: Jeg dokumenterer disse justeringer, fordi de har en subtil virkning, og jeg i tvivlstilf\u00e6lde hurtigt har brug for at kunne fortryde dem.<\/p>\n\n<h2>S\u00e5dan udnytter du SMT\/Hyper-Threading og topologi optimalt<\/h2>\n<p>N\u00e5r SMT er aktiveret, deler jeg en fysisk kerne med to logiske CPU\u2019er. Jeg tjekker s\u00f8skendeforholdene via <code>lscpu -e<\/code> og <code>\/sys\/devices\/system\/cpu\/cpuX\/topology\/thread_siblings_list<\/code>. For latenstidsf\u00f8lsomme forl\u00f8b undg\u00e5r jeg at placere app-tr\u00e5den og den tilh\u00f8rende IRQ p\u00e5 samme fysiske kerne (forskellige SMT-tr\u00e5de), da de konkurrerer om eksekveringsenheder og cacher. Jeg foretr\u00e6kker kombinationer, hvor f.eks. en app-tr\u00e5d k\u00f8rer p\u00e5 CPU2 og den tilh\u00f8rende RX-k\u00f8 p\u00e5 CPU3 (anden fysisk kerne, samme NUMA-knude). Hvis SMT forstyrrer stabiliteten, planl\u00e6gger jeg i stedet med f\u00e6rre, men eksklusive fysiske kerner og sparer mig selv for ustabilitet <strong>Interferenser<\/strong>.<\/p>\n\n<h2>Virtualisering: KVM, vhost og SR-IOV<\/h2>\n<p>I virtualiserede milj\u00f8er betragter jeg v\u00e6rten og g\u00e6sten som to separate enheder. P\u00e5 v\u00e6rten fordeler jeg de fysiske NIC-IRQ\u2019er j\u00e6vnt mellem kernerne i den relevante NUMA-node. Hvis g\u00e6sten bruger virtio-net, opst\u00e5r der yderligere IRQ\u2019er til vhost-tr\u00e5de; jeg genkender dem i <code>\/proc\/afbrydelser<\/code> og tildeler vhost-workere konsekvent til k\u00f8erne p\u00e5 det fysiske netv\u00e6rkskort. P\u00e5 g\u00e6steniveau indstiller jeg ligeledes RSS\/XPS og IRQ-affiniteter, forudsat at virtio-driveren stiller flere k\u00f8er til r\u00e5dighed. Ved SR-IOV er det en god id\u00e9 at tildele hver g\u00e6st en eller flere VF\u2019er med egne MSI-X-vektorer og at fastl\u00e5se disse i g\u00e6sten; isolationen forbedrer latenstiden og forudsigeligheden. Jeg f\u00f8lger et klart m\u00f8nster: g\u00e6stens vCPU\u2019er p\u00e5 dedikerede pCPU\u2019er, tilh\u00f8rende IRQ\u2019er p\u00e5 n\u00e6rliggende kerner, og emulator-\/vhost-tr\u00e5de m\u00e5 ikke blandes med regnekraftskr\u00e6vende app-tr\u00e5de \u2013 s\u00e5 forbliver datavejen <strong>planl\u00e6gbar<\/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-frekvens, C-tilstande og NOHZ-tuning<\/h2>\n<p>IRQ-forsinkelser forv\u00e6rres, n\u00e5r kerner g\u00e5r ned i dybe C-tilstande eller k\u00f8rer med aggressiv takting. Til f\u00f8lsomme arbejdsbelastninger indstiller jeg CPU-governoren til <code>ydeevne<\/code> (<code>cpupower frequency\u2011set -g performance<\/code>) og reducerer dybe C-tilstande via boot- eller driverindstillinger for at begr\u00e6nse opv\u00e5gningstiderne. P\u00e5 servere med h\u00f8j belastning har dette ofte en mere positiv effekt end enhver finjustering af affiniteterne. I meget strenge latenstidsprofiler tilf\u00f8jer jeg <code>nohz_full=<\/code> og <code>rcu_nocbs=<\/code> til isolerede kerner, s\u00e5 tick-timere og RCU-call-backs ikke forstyrrer hinanden; jeg definerer bevidst housekeeping-CPU\u2019erne separat. Disse \u00e6ndringer tester jeg dog hver for sig, da de kan have bivirkninger p\u00e5 skemastyring og energiforbrug. Det afg\u00f8rende er stadig: at sammenligne m\u00e5lev\u00e6rdierne f\u00f8r og efter \u00e6ndringen n\u00f8je, ellers g\u00e5r jeg p\u00e5 vildspor ved <strong>Optimeringer<\/strong> i m\u00f8rket.<\/p>\n\n<h2>Systemd, Cgroups og app-isolering<\/h2>\n<p>Ud over IRQ-pinning adskiller jeg app-tr\u00e5de ved hj\u00e6lp af Cgroups og systemd-affinity. Via <code>CPUAffinitet=.<\/code> I Unit-filer og CPU-controllerne (cgroup v2) tildeler jeg tjenester faste kerner. P\u00e5 den m\u00e5de forhindrer jeg, at tr\u00e5de fra scheduler-siden glider over p\u00e5 de CPU\u2019er, som jeg har afsat til IRQ\u2019er. I container-milj\u00f8er indstiller jeg <code>cpuset.cpus<\/code> og tjekke <code>cpuset.cpus.effective<\/code>, s\u00e5 l\u00f8fterne om ressourcer virkelig bliver til noget. Vigtigt: <code>IRQBALANCE_BANNED_CPUS<\/code> styrer kun de omr\u00e5der, hvor irqbalance ikke fordeler; kernel-tr\u00e5de som ksoftirqd f\u00f8lger fortsat scheduleren. For at opn\u00e5 h\u00e5rd isolation har jeg derfor brug for en kombination af IRQ-affiniteter, tjenesternes CPU-affinitet og eventuelt isolerede kerner. P\u00e5 den m\u00e5de forbliver datavejen og applikationen klart adskilt, og <strong>Belastning<\/strong> blandes ikke ukontrolleret.<\/p>\n\n<h2>Typiske fejl og afhj\u00e6lpende foranstaltninger<\/h2>\n<p>Jeg deaktiverer aldrig irqbalance generelt, uden at kende belastningsm\u00f8nstrene; ellers samler IRQ\u2019erne sig hurtigt p\u00e5 nogle f\u00e5 kerner. Det er ligeledes uheldigt at \u00e5bne alle kerner for alle IRQ\u2019er, selvom f\u00f8lsomme tr\u00e5de er eksklusive <strong>Ressourcer<\/strong> har brug for. En anden fejl: Man tester ikke \u00e6ndringer isoleret og m\u00e5ler ikke effekterne; dermed forbliver det uklart, hvad der rent faktisk hj\u00e6lper. Jeg tager ogs\u00e5 h\u00f8jde for Hyper-Threading-par: App-tr\u00e5d og tilh\u00f8rende IRQ b\u00f8r helst ikke dele den samme fysiske kerne. Jeg dokumenterer hvert trin og opretter rollback-punkter, s\u00e5 jeg hurtigt kan vende tilbage til den sidste <strong>godt<\/strong> Tilbage til konfigurationen.<\/p>\n\n<h2>Tjekliste til serverdrift<\/h2>\n<p>Jeg starter altid med en baseline: irqbalance aktiveret, registrering af systembelastning, overv\u00e5gning af \/proc\/interrupts og m\u00e5ling af latenstider; f\u00f8rst derefter \u00e6ndrer jeg indstillingerne. I det n\u00e6ste trin afslutter jeg med <code>IRQBALANCE_BANNED_CPUS<\/code> udv\u00e6lger de kerner, der skal forbeholdes app-tr\u00e5de; p\u00e5 den m\u00e5de undg\u00e5r jeg un\u00f8dvendige IRQ-afbrydelser. Derefter tildeler jeg kritiske IRQ\u2019er via <code>smp_affinity<\/code> p\u00e5 f\u00e5, velvalgte kerner og sikrer NUMA-n\u00e6rhed. Derefter tjekker jeg RSS\/RPS\/RFS og XPS samt NIC\u2019ens offloading-muligheder for at fordele arbejdet p\u00e5 en fornuftig m\u00e5de. Til sidst tester jeg under produktionsbelastning, sammenligner m\u00e5lev\u00e6rdier og beholder kun de \u00e6ndringer, der p\u00e5viseligt <strong>arbejde<\/strong>.<\/p>\n\n<h2>Konfigurationsfiler og systemd-kommandoer<\/h2>\n<p>Jeg aktiverer tjenesten med <code>systemctl enable --now irqbalance<\/code> og tjek med <code>systemctl status irqbalance<\/code> l\u00f8betiden; s\u00e5 indstiller jeg den <strong>Service<\/strong> helt sikkert klar. I <code>\/etc\/sysconfig\/irqbalance<\/code> eller <code>\/etc\/default\/irqbalance<\/code> s\u00e6tter jeg <code>IRQBALANCE_BANNED_CPUS<\/code> samt valgfrit <code>IRQBALANCE_BANNED_IRQS<\/code>. \u00c6ndringerne tager jeg med <code>systemctl restart irqbalance<\/code> og f\u00f8lger samtidig t\u00e6llerne i <code>\/proc\/afbrydelser<\/code>. Til test bruger jeg irqbalance\u2019s foreground-tilstand for at f\u00f8lge beslutningerne i realtid. F\u00f8rst n\u00e5r jeg forst\u00e5r, hvordan det fungerer, skriver jeg \u00e6ndringerne permanent ind i <strong>Konfiguration<\/strong>.<\/p>\n\n<h2>N\u00e5r jeg deaktiverer irqbalance<\/h2>\n<p>I realtidsops\u00e6tninger eller ved applikationer, der er ekstremt f\u00f8lsomme over for latenstid, stopper jeg irqbalance og tildeler IRQ\u2019er statisk, s\u00e5 ingen omfordeling forstyrrer. Jeg isolerer kernerne til disse arbejdsbelastninger og lader trafik-IRQ\u2019er bevidst k\u00f8re p\u00e5 andre kerner; p\u00e5 den m\u00e5de forbliver applikationstr\u00e5de <strong>planl\u00e6gbar<\/strong>. Selv i tilf\u00e6lde af strengt adskilte tenant-milj\u00f8er er denne fremgangsm\u00e5de en fordel, fordi jeg dermed mindsker interferensen mellem VM\u2019er eller containere. Hvis der opst\u00e5r drivere, der fungerer d\u00e5rligere med den automatiske indstilling, udelukker jeg deres IRQ\u2019er via en banned-liste. S\u00e5 snart belastningsm\u00f8nstrene igen bliver mere varierende, aktiverer jeg irqbalance igen og kontrollerer effekten med nye <strong>M\u00e5lte v\u00e6rdier<\/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 opsummeret<\/h2>\n<p>Jeg starter med irqbalance, m\u00e5ler effekten og foretager selektive justeringer i stedet for at gribe ind overalt uden at t\u00e6nke mig om; p\u00e5 den m\u00e5de bevarer jeg overblikket over systemet og <strong>Gennemsigtighed<\/strong>. Til f\u00f8lsomme arbejdsbelastninger tildeler jeg passende IRQ\u2019er, isolerer kerner til applikationer og tager h\u00f8jde for NUMA-n\u00e6rhed. Ved hj\u00e6lp af banned-masker styrer jeg, hvor irqbalance m\u00e5 operere, og forhindrer u\u00f8nskede flytninger. Jeg kontrollerer regelm\u00e6ssigt <code>\/proc\/afbrydelser<\/code>, latenstid og gennemstr\u00f8mning, s\u00e5 \u00e6ndringerne er underbygget af p\u00e5lidelige data. Den, der arbejder p\u00e5 denne m\u00e5de, udnytter IRQ Balances potentiale fuldt ud og holder serverne m\u00e6rkbart under netv\u00e6rksbelastning <strong>reaktiv<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>S\u00e5dan indstilles irqbalance korrekt i Linux: S\u00e5dan fordeler du interrupts effektivt p\u00e5 Linux-servere og forbedrer ydeevnen.<\/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":"149","_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\/da\/wp-json\/wp\/v2\/posts\/21042","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=21042"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21042\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/21035"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=21042"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=21042"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=21042"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}