Videre til indhold 
IRQ Balance styrer under Linux fordelingen af hardware-interrupts på CPU-kerner og afgør dermed, om netværksbelastningen fordeles jævnt, eller om enkelte kerner bliver overbelastet. Jeg viser dig, hvordan du anvender irqbalance målrettet, hvornår jeg skifter til manuel IRQ-affinitet, og hvilke indstillinger der er optimale på servere med høj netværksbelastning virkelig tæller.
Centrale punkter
Inden jeg går i detaljer, vil jeg sammenfatte de vigtigste beslutninger, der pålideligt har hjulpet mig i projekter med høj I/O-belastning. Jeg anser den automatiske fordeling via irqbalance for at være et fornuftigt udgangspunkt, måler effekten og foretager selektive justeringer. Ved deterministiske arbejdsbelastninger tildeler jeg enkelte IRQ’er manuelt til bestemte kerner og udelukker de øvrige CPU’er fra den automatiske fordeling. Jeg tager højde for NUMA-nærhed på et tidligt tidspunkt, da det reducerer latenstiden og sikrer gennemløbshastigheden. Med en tydelig overvågning opdager jeg flaskehalse hurtigere og regulerer dem uden unødvendige Risici.
Denne liste viser dig, hvad jeg lægger særlig vægt på ved konfigurationen:
- Automatisk Først: Aktiver irqbalance, mål effekten
- affinitet målrettet: fastlåse kritiske IRQ’er, reducere jitter
- Forbudte CPU'er: Hold plads til kerner til app-tråde
- NUMA Bemærk: Hold IRQ’er tæt på hukommelsesknudepunkterne
- Overvågning: Kontroller /proc/interrupts og ventetiderne
IRQ-grundbegreber kort forklaret
En interrupt-anmodning (IRQ) er et signal, hvorved hardware overdrager arbejde til CPU’en og dermed afbryder en igangværende 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 Distribution undgå. irqbalance fordeler disse IRQ’er dynamisk på flere kerner og vurderer systemtilstanden med jævne mellemrum. Jeg ser først på /proc/afbrydelser og se i kolonnerne, hvor mange IRQ’er der kommer pr. CPU. Hvis enkelte kolonner bliver for store, justerer jeg aktivt og reducerer dermed unødvendige Hotspots.
Automatisk fordeling med irqbalance
På moderne distributioner starter jeg med tjenesten irqbalance, som som standard jævnligt justerer IRQ-fordelingen. Jeg aktiverer den med systemctl enable --now irqbalance og tjekker status, før jeg går mere i dybden; på den måde udnytter jeg det eksisterende Automatisk. Konfigurationsfilerne findes, afhængigt af systemet, i /etc/sysconfig/irqbalance eller /etc/default/irqbalance, der kan jeg udelukke CPU’er eller IRQ’er. Variablen er særligt nyttig IRQBALANCE_BANNED_CPUS som en 64-bit-maske til at reservere bestemte kerner til applikationer. Hvis man ønsker at dykke dybere ned i praktiske eksempler, finder man her en kortfattet introduktion til Netværksydelse, som jeg ofte henviser til i workshops og anvender i projekter.
Sikker implementering af manuel IRQ-affinitet
Hvis arbejdsbelastninger er meget følsomme over for jitter, eller hvis bestemte kerner skal holdes frie udelukkende til brugerrumsprocesser, indstiller jeg IRQ-affinitet manuelt. Til det formål skriver jeg bitmasker efter /proc/irq/IRQ-NUMMER/smp_affinity og fastlægger, på hvilke kerner en interrupt må køre; det skaber planlægningssikkerhed Adfærd. Først finder jeg de relevante IRQ-numre ved hjælp af grep på /proc/afbrydelser. For netværksenheder tildeler jeg ofte RX/TX-køer til kerner, der ligger tæt på app-trådene, mens jeg holder andre kerner fri. Denne korte artikel giver en god baggrund for denne fremgangsmåde Vejledning i IRQ-affinitet, som jeg regelmæssigt bruger som udgangspunkt.
Den følgende tabel viser almindelige bitmasker og deres betydning. Jeg bruger disse eksempler til hurtigt og fejlfrit at indstille konfigurationer og derefter kontrollere effekten med /proc/afbrydelser til verificere.
| Mål | Eksempel på maske (hex) | Kerner | Kommentar |
|---|---|---|---|
| Kun CPU0 | 0x1 | 0 | Enkel test, lav spredning |
| Kun CPU1 | 0x2 | 1 | Adskiller IRQ’er fra CPU0, sænker Interferens |
| CPU0–CPU1 | 0x3 | 0–1 | Fordelt på to kerner, let Aflastning |
| CPU2–CPU3 | 0xC | 2-3 | Nyttigt, når 0–1 gælder for app-tråde gratis ophold |
| CPU0–CPU3 | 0xF | 0–3 | Bred spredning over 4 kerner, blander Belastning |
Måling: Korrekt aflæsning af /proc/interrupts
Jeg åbner filen /proc/afbrydelser og ser en IRQ pr. række samt tællerne pr. CPU pr. kolonne; det afslører straks ubalancer synlig. Hvis en kolonne vokser markant hurtigere end de andre, koncentreres belastningen der. Så undersøger 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å dens beslutninger og undgå fejlvurderinger. Efter hver ændring kontrollerer jeg tællerne igen og måler latenstiden under belastning, så jeg kan dokumentere effekterne og undgå unødvendige Risici kan undgå.
CPU-isolering og forbudte masker
Jeg sætter IRQBALANCE_BANNED_CPUS, for konsekvent at udelukke bestemte kerner fra den automatiske fordeling; på den måde holder jeg ressourcer fri til app-tråde. I nyere opsætninger bruger jeg desuden IRQBALANCE_BANNED_IRQS, hvis enkelte enheder skal køre uafhængigt på en kerne; det mindsker forstyrrelser for følsomme Arbejdsbyrder. I scenarier med lav latenstid deaktiverer jeg målrettet irqbalance og tildeler IRQ’er statisk, så der ikke sker nogen omfordeling, der forstyrrer. Hvis man ønsker at forstå CPU-tildelingen af interrupt-håndtering bedre, kan man finde nyttige baggrundsoplysninger om Håndtering af afbrydelser på servere. Det vigtige er stadig: først måle, derefter fastlægge og igen kontrollere effekten for at undgå overraskelser i Betjening for at undgå.
NUMA-aspekter og nærhed
På NUMA-systemer sørger jeg for så vidt muligt at dirigere IRQ’er til kerner på den NUMA-node, hvor de pågældende data ligger i hukommelsen; det mindsker latenstiden og øger Gennemstrømning. Jeg kombinerer dette med CPU-affinitet for applikationen, så tråde og interrupts kører lokalt i forhold til hinanden. irqbalance fungerer godt på NUMA, men jeg justerer efter behov ved hjælp af banned-masker. Det er afgørende ikke at sprede belastningen på tværs af noder, når den alligevel kan holdes lokalt. Hvis man opretholder denne nærhed, opnår man konstante responstider og skåner værdifulde Cache-Ressourcer.
Netværksintensivt kursus: RSS, RPS/RFS og XPS
Inden jeg finjusterer IRQ-maskerne, tjekker jeg NIC-funktioner som RSS samt kerne-mekanismer som RPS/RFS og XPS; de har stor indflydelse på fordelingen af pakker. RSS fordeler kø-interrupts allerede på flere kerner, mens RPS/RFS styrer behandlingen i kernen og XPS former sendestierne; dette undgår unødvendige Hotspots. Jeg afstemmer disse mekanismer med min IRQ-strategi, så de ikke modarbejder hinanden. Hvis køerne, IRQ-affinitetene og app-affiniteten stemmer overens, kører netværks-I/O betydeligt mere smidigt. Derefter måler jeg igen under reel belastning, før jeg fortsætter med yderligere Trin sæt.
MSI‑X, Multi‑Queue og et overskueligt kø-layout
Mange 10–100G-NIC’er bruger MSI-X og stiller egne interrupt-vektorer til rådighed for hver RX/TX-kø. Jeg tjekker først med ethtool -l eth0 (antal kanaler) og /proc/afbrydelser, hvor mange køer der rent faktisk er aktive, og hvad de hedder (f.eks. eth0-TxRx-0, eth0-TxRx-1). Målet er at tilpasse antallet af køer til antallet af anvendte kerner pr. NUMA-node og fastlåse disse på en deterministisk måde. Med ethtool -L eth0 combined N indstiller jeg antallet af køer; derefter sorterer jeg de genererede IRQ’er ved hjælp af smp_affinity passende kerner. Jeg sørger for, at RX/TX-par fra samme kø placeres på samme kerne eller i det mindste samme socket, så Cache-placering gælder. Vigtigt: Ændringer i kø-tal og affinitet tjekker jeg direkte i /proc/afbrydelser og med en kort belastningstest (pps/throughput), inden jeg fortsætter med at optimere.
Interrupt-koalescens og NAPI-budget
Især ved høje pakkefrekvenser påvirker koalescensværdierne effektiviteten af min IRQ-strategi. Med ethtool -c eth0 kan jeg se, om rx-usecs og rx-rammer er indstillet. Mere koalescens reducerer antallet af IRQ’er pr. sekund og sparer CPU-ressourcer, men øger latenstiden og jitteren. Jeg justerer forsigtigt: små skridt, hvor jeg hver gang måler (p95/p99-latenstid og CPU-belastning). På sendersiden virker tx-usecs analogt. Derudover skalerer jeg NAPI-adfærden via net.core.netdev_budget og net.core.netdev_budget_usecs, når NET_RX begynder at hober sig op i SoftIRQ’erne. Hvis antallet af drops stiger i /proc/net/softnet_stat, øger jeg budgettet som et forsøg eller fordeler RX-køerne mere konsekvent; hvis systemforsinkelsen bliver for stor, skruer jeg ned igen. Jeg tager højde for GRO/LRO og TSO/GSO i samspil: Overdreven aggregering sænker IRQ-belastningen, men kan skabe latenstop – jeg afbalancerer dem med applikationsprofilen.
Transparent aflæsning af SoftIRQ'er
Ud over HardIRQ’er bestemmer jeg belastningen i SoftIRQ’er. Med cat /proc/softirqs Jeg observerer NET_RX og NET_TX pr. CPU; hvis enkelte kolonner dominerer, ender for meget arbejde der i ksoftirqd-tråde. En top -H vis mig hurtigt, hvilke ksoftirqd/N Kerner belaster. Jeg måler dybere med perf top eller korte perf-rekord Kører for at identificere hotspots i driveren eller i stakbehandlingen. Hvis ksoftirqd-tråde bliver aktive (i stedet for direkte behandling i IRQ-konteksten), stiger latenstiden ofte markant; jeg reagerer med bedre køfordeling, større NAPI-budget eller målrettet CPU-pinning af de berørte ksoftirqd-tråde via taskset -pc. Vigtigt: Jeg dokumenterer disse justeringer, fordi de har en subtil virkning, og jeg i tvivlstilfælde hurtigt har brug for at kunne fortryde dem.
Sådan udnytter du SMT/Hyper-Threading og topologi optimalt
Når SMT er aktiveret, deler jeg en fysisk kerne med to logiske CPU’er. Jeg tjekker søskendeforholdene via lscpu -e og /sys/devices/system/cpu/cpuX/topology/thread_siblings_list. For latenstidsfølsomme forløb undgår jeg at placere app-tråden og den tilhørende IRQ på samme fysiske kerne (forskellige SMT-tråde), da de konkurrerer om eksekveringsenheder og cacher. Jeg foretrækker kombinationer, hvor f.eks. en app-tråd kører på CPU2 og den tilhørende RX-kø på CPU3 (anden fysisk kerne, samme NUMA-knude). Hvis SMT forstyrrer stabiliteten, planlægger jeg i stedet med færre, men eksklusive fysiske kerner og sparer mig selv for ustabilitet Interferenser.
Virtualisering: KVM, vhost og SR-IOV
I virtualiserede miljøer betragter jeg værten og gæsten som to separate enheder. På værten fordeler jeg de fysiske NIC-IRQ’er jævnt mellem kernerne i den relevante NUMA-node. Hvis gæsten bruger virtio-net, opstår der yderligere IRQ’er til vhost-tråde; jeg genkender dem i /proc/afbrydelser og tildeler vhost-workere konsekvent til køerne på det fysiske netværkskort. På gæsteniveau indstiller jeg ligeledes RSS/XPS og IRQ-affiniteter, forudsat at virtio-driveren stiller flere køer til rådighed. Ved SR-IOV er det en god idé at tildele hver gæst en eller flere VF’er med egne MSI-X-vektorer og at fastlåse disse i gæsten; isolationen forbedrer latenstiden og forudsigeligheden. Jeg følger et klart mønster: gæstens vCPU’er på dedikerede pCPU’er, tilhørende IRQ’er på nærliggende kerner, og emulator-/vhost-tråde må ikke blandes med regnekraftskrævende app-tråde – så forbliver datavejen planlægbar.
CPU-frekvens, C-tilstande og NOHZ-tuning
IRQ-forsinkelser forværres, når kerner går ned i dybe C-tilstande eller kører med aggressiv takting. Til følsomme arbejdsbelastninger indstiller jeg CPU-governoren til ydeevne (cpupower frequency‑set -g performance) og reducerer dybe C-tilstande via boot- eller driverindstillinger for at begrænse opvågningstiderne. På servere med høj belastning har dette ofte en mere positiv effekt end enhver finjustering af affiniteterne. I meget strenge latenstidsprofiler tilføjer jeg nohz_full= og rcu_nocbs= til isolerede kerner, så tick-timere og RCU-call-backs ikke forstyrrer hinanden; jeg definerer bevidst housekeeping-CPU’erne separat. Disse ændringer tester jeg dog hver for sig, da de kan have bivirkninger på skemastyring og energiforbrug. Det afgørende er stadig: at sammenligne måleværdierne før og efter ændringen nøje, ellers går jeg på vildspor ved Optimeringer i mørket.
Systemd, Cgroups og app-isolering
Ud over IRQ-pinning adskiller jeg app-tråde ved hjælp af Cgroups og systemd-affinity. Via CPUAffinitet=. I Unit-filer og CPU-controllerne (cgroup v2) tildeler jeg tjenester faste kerner. På den måde forhindrer jeg, at tråde fra scheduler-siden glider over på de CPU’er, som jeg har afsat til IRQ’er. I container-miljøer indstiller jeg cpuset.cpus og tjekke cpuset.cpus.effective, så løfterne om ressourcer virkelig bliver til noget. Vigtigt: IRQBALANCE_BANNED_CPUS styrer kun de områder, hvor irqbalance ikke fordeler; kernel-tråde som ksoftirqd følger fortsat scheduleren. For at opnå hård isolation har jeg derfor brug for en kombination af IRQ-affiniteter, tjenesternes CPU-affinitet og eventuelt isolerede kerner. På den måde forbliver datavejen og applikationen klart adskilt, og Belastning blandes ikke ukontrolleret.
Typiske fejl og afhjælpende foranstaltninger
Jeg deaktiverer aldrig irqbalance generelt, uden at kende belastningsmønstrene; ellers samler IRQ’erne sig hurtigt på nogle få kerner. Det er ligeledes uheldigt at åbne alle kerner for alle IRQ’er, selvom følsomme tråde er eksklusive Ressourcer har brug for. En anden fejl: Man tester ikke ændringer isoleret og måler ikke effekterne; dermed forbliver det uklart, hvad der rent faktisk hjælper. Jeg tager også højde for Hyper-Threading-par: App-tråd og tilhørende IRQ bør helst ikke dele den samme fysiske kerne. Jeg dokumenterer hvert trin og opretter rollback-punkter, så jeg hurtigt kan vende tilbage til den sidste godt Tilbage til konfigurationen.
Tjekliste til serverdrift
Jeg starter altid med en baseline: irqbalance aktiveret, registrering af systembelastning, overvågning af /proc/interrupts og måling af latenstider; først derefter ændrer jeg indstillingerne. I det næste trin afslutter jeg med IRQBALANCE_BANNED_CPUS udvælger de kerner, der skal forbeholdes app-tråde; på den måde undgår jeg unødvendige IRQ-afbrydelser. Derefter tildeler jeg kritiske IRQ’er via smp_affinity på få, velvalgte kerner og sikrer NUMA-nærhed. Derefter tjekker jeg RSS/RPS/RFS og XPS samt NIC’ens offloading-muligheder for at fordele arbejdet på en fornuftig måde. Til sidst tester jeg under produktionsbelastning, sammenligner måleværdier og beholder kun de ændringer, der påviseligt arbejde.
Konfigurationsfiler og systemd-kommandoer
Jeg aktiverer tjenesten med systemctl enable --now irqbalance og tjek med systemctl status irqbalance løbetiden; så indstiller jeg den Service helt sikkert klar. I /etc/sysconfig/irqbalance eller /etc/default/irqbalance sætter jeg IRQBALANCE_BANNED_CPUS samt valgfrit IRQBALANCE_BANNED_IRQS. Ændringerne tager jeg med systemctl restart irqbalance og følger samtidig tællerne i /proc/afbrydelser. Til test bruger jeg irqbalance’s foreground-tilstand for at følge beslutningerne i realtid. Først når jeg forstår, hvordan det fungerer, skriver jeg ændringerne permanent ind i Konfiguration.
Når jeg deaktiverer irqbalance
I realtidsopsætninger eller ved applikationer, der er ekstremt følsomme over for latenstid, stopper jeg irqbalance og tildeler IRQ’er statisk, så ingen omfordeling forstyrrer. Jeg isolerer kernerne til disse arbejdsbelastninger og lader trafik-IRQ’er bevidst køre på andre kerner; på den måde forbliver applikationstråde planlægbar. Selv i tilfælde af strengt adskilte tenant-miljøer er denne fremgangsmåde en fordel, fordi jeg dermed mindsker interferensen mellem VM’er eller containere. Hvis der opstår drivere, der fungerer dårligere med den automatiske indstilling, udelukker jeg deres IRQ’er via en banned-liste. Så snart belastningsmønstrene igen bliver mere varierende, aktiverer jeg irqbalance igen og kontrollerer effekten med nye Målte værdier.
Kort opsummeret
Jeg starter med irqbalance, måler effekten og foretager selektive justeringer i stedet for at gribe ind overalt uden at tænke mig om; på den måde bevarer jeg overblikket over systemet og Gennemsigtighed. Til følsomme arbejdsbelastninger tildeler jeg passende IRQ’er, isolerer kerner til applikationer og tager højde for NUMA-nærhed. Ved hjælp af banned-masker styrer jeg, hvor irqbalance må operere, og forhindrer uønskede flytninger. Jeg kontrollerer regelmæssigt /proc/afbrydelser, latenstid og gennemstrømning, så ændringerne er underbygget af pålidelige data. Den, der arbejder på denne måde, udnytter IRQ Balances potentiale fuldt ud og holder serverne mærkbart under netværksbelastning reaktiv.
