Hoppa till innehåll 
IRQ Balance styr fördelningen av hårdvaruavbrott mellan CPU-kärnorna i Linux och avgör därmed om nätverksbelastningen fördelas jämnt eller om enskilda kärnor bromsas upp. Jag visar dig hur du använder irqbalance på ett målinriktat sätt, när jag byter till manuell IRQ-affinitet och vilka inställningar som är lämpliga på servrar med hög nätverksbelastning verkligen betyder något.
Centrala punkter
Innan jag går in på detaljerna sammanfattar jag de viktigaste besluten som på ett tillförlitligt sätt har hjälpt mig i projekt med hög I/O-belastning. Jag anser att automatisk fördelning via irqbalance är en bra utgångspunkt, mäter effekten och justerar selektivt. Vid deterministiska arbetsbelastningar kopplar jag enskilda IRQ:er manuellt till specifika kärnor och utesluter övriga CPU:er från den automatiska fördelningen. Jag tar hänsyn till NUMA-närhet redan i ett tidigt skede, eftersom det minskar latensen och säkerställer genomströmningen. Med tydlig övervakning upptäcker jag flaskhalsar snabbare och reglerar dem utan onödiga Risker.
Den här listan visar vad jag lägger särskilt stor vikt vid när jag gör inställningarna:
- Automatisk Först: aktivera irqbalance, mäta effekten
- affinitet målmedvetet: låsa kritiska IRQ:er, minska jitter
- Förbjudna processorer: Håll utrymme ledigt för apptrådar
- NUMA Observera: Håll IRQ:erna nära minnesnoden
- Övervakning: Kontrollera /proc/interrupts och latenser
IRQ-grunderna i korthet
En avbrottsbegäran (IRQ) är en signal som hårdvaran använder för att överlämna arbete till CPU:n och därmed avbryta en pågående uppgift. Om för många av dessa signaler når samma kärna ökar belastningen där och svarstiden blir långsam, medan andra kärnor förblir outnyttjade; det är precis det jag vill åstadkomma med Distribution undvika. irqbalance fördelar dessa IRQ:er dynamiskt över flera kärnor och utvärderar systemets tillstånd med jämna mellanrum. Jag tittar först på /proc/avbrott och se i kolumnerna hur många IRQ:er som kommer in per CPU. Om enskilda kolumner blir för stora justerar jag aktivt och minskar därmed onödiga Hotspots.
Automatisk fördelning med irqbalance
På moderna distributioner startar jag med tjänsten irqbalance, som som standard periodvis justerar IRQ-fördelningen. Jag aktiverar den med systemctl enable --now irqbalance och kontrollerar statusen innan jag går in djupare; på så sätt utnyttjar jag det befintliga Automatisk. Konfigurationsfilerna finns, beroende på system, i /etc/sysconfig/irqbalance eller . /etc/default/irqbalance, där kan jag utesluta CPU:er eller IRQ:er. Särskilt användbar är variabeln IRQBALANCE_BANNED_CPUS som en 64-bitarsmask för att reservera definierade kärnor för applikationer. Den som vill fördjupa sig i praktiska exempel hittar här en kortfattad introduktion till Nätverksprestanda, som jag ofta hänvisar till i workshoppar och använder i projekt.
Säker implementering av manuell IRQ-affinitet
Om arbetsbelastningar är mycket känsliga för jitter eller om vissa kärnor ska hållas fria uteslutande för processer i användarutrymmet, ställer jag in IRQ-affinitet manuellt. För detta skriver jag in bitmasker enligt /proc/irq/IRQ-NUMMER/smp_affinity och fastställer på vilka kärnor en avbrottshändelse får köras; det gör det möjligt att planera Beteende. Först tar jag reda på de relevanta IRQ-numren med grep på /proc/avbrott. När det gäller nätverksenheter kopplar jag ofta RX/TX-köer till kärnor som ligger nära apptrådarna, medan jag håller andra kärnor fria. Denna korta artikel sammanfattar bra bakgrundsinformation om denna metod Guide till IRQ-affinitet, som jag regelbundet använder som utgångspunkt.
Tabellen nedan visar vanliga bitmasker och vad de betyder. Jag använder dessa exempel för att snabbt och med få fel ställa in konfigurationer och sedan kontrollera effekten med /proc/avbrott till verifiera.
| Mål | Exempel på mask (hex) | kärnor | Kommentar |
|---|---|---|---|
| Endast CPU0 | 0x1 | 0 | Enkel test, låg spridning |
| Endast CPU1 | 0x2 | 1 | Avskiljer IRQ:er från CPU0, minskar Interferens |
| CPU0–CPU1 | 0x3 | 0–1 | Fördelat på två kärnor, lätt Avlastning |
| CPU2–CPU3 | 0xC | 2-3 | Användbart när 0–1 gäller för apptrådar fri stanna |
| CPU0–CPU3 | 0xF | 0–3 | Bred spridning över 4 kärnor, blandad Last |
Mätning: Läsa /proc/interrupts korrekt
Jag öppnar filen /proc/avbrott och ser en IRQ per rad samt räknarna per CPU i varje kolumn; det visar omedelbart obalanser synlig. Om en kolumn växer betydligt snabbare än andra, koncentreras belastningen där. Då kontrollerar jag vilken drivrutin som är inblandad och om RSS/RPS redan har fördelats. Dessutom startar jag irqbalance tillfälligt i förgrunden med felsökningsutdata för att förstå dess beslut och undvika felbedömningar. Efter varje ändring kontrollerar jag räknarna på nytt och mäter latensen under belastning, så att jag kan belägga effekterna och undvika onödiga Risker kan undvika.
CPU-isolering och förbjudna masker
Jag ställer in IRQBALANCE_BANNED_CPUS, för att konsekvent undanta vissa kärnor från den automatiska fördelningen; på så sätt håller jag resurser fria för app-trådar. I nyare konfigurationer använder jag dessutom IRQBALANCE_BANNED_IRQS, om enskilda enheter ska köras självständigt på en kärna; detta minskar störningar för känsliga Arbetsbelastning. I scenarier med låg latens inaktiverar jag irqbalance medvetet och tilldelar IRQ:er statiskt, så att ingen omfördelning stör. Den som vill förstå CPU-tilldelningen vid avbrottshantering bättre hittar användbar bakgrundsinformation om Hantering av avbrott på servrar. Det viktiga är fortfarande: mäta först, fastställa sedan och återigen kontrollera effekten för att undvika överraskningar i Drift som ska undvikas.
NUMA-aspekter och närhet
På NUMA-system ser jag till att IRQ:er i möjligaste mån dirigeras till kärnorna i den NUMA-nod där de aktuella uppgifterna finns i minnet; detta minskar latensen och ökar Genomströmning. Jag kombinerar detta med CPU-affinitet för applikationen, så att trådar och avbrott körs lokalt i förhållande till varandra. irqbalance fungerar bra på NUMA, men vid behov justerar jag med banned-masker. Det är viktigt att inte sprida belastningen över noder när den ändå kan hållas lokalt. Den som upprätthåller denna närhet får konstanta svarstider och sparar värdefull Cache-Resurser.
Nätverksintensivkurs: RSS, RPS/RFS och XPS
Innan jag finjusterar IRQ-maskerna kontrollerar jag nätverkskortets funktioner, såsom RSS, samt kärnmekanismer som RPS/RFS och XPS; dessa påverkar paketfördelningen i hög grad. RSS fördelar köavbrott redan på flera kärnor, medan RPS/RFS styr bearbetningen i kärnan och XPS formar sändningsvägarna; detta undviker onödiga Hotspots. Jag anpassar dessa mekanismer efter min IRQ-strategi så att de inte motverkar varandra. Om köerna, IRQ-affiniteterna och app-affiniteten stämmer överens fungerar nätverks-I/O betydligt smidigare. Därefter mäter jag igen under verklig belastning innan jag fortsätter med ytterligare Steg sätt.
MSI-X, Multi-Queue och en överskådlig köstruktur
Många 10–100G-NIC:ar använder MSI-X och tillhandahåller egna avbrottsvektorer per RX/TX-kö. Jag kontrollerar först med ethtool -l eth0 (antal kanaler) och /proc/avbrott, hur många köer som faktiskt är aktiva och vad de heter (t.ex. eth0-TxRx-0, eth0-TxRx-1). Målet är att anpassa antalet köer efter antalet använda kärnor per NUMA-nod och att fästa dessa på ett deterministiskt sätt. Med ethtool -L eth0 combined N ställer jag in antalet köer; därefter ordnar jag de IRQ:er som uppstår genom smp_affinity lämpliga kärnor. Jag ser till att placera RX/TX-par från samma kö på samma kärna eller åtminstone samma socket, så att Cache-plats gäller. Viktigt: Ändringar av köantal och affinitet kontrollerar jag direkt i /proc/avbrott och med ett kort belastningstest (pps/genomströmning) innan jag fortsätter att optimera.
Interrupt-koalescens och NAPI-budget
Särskilt vid höga paketfrekvenser påverkar koalescensvärdena effektiviteten hos min IRQ-strategi. Med ethtool -c eth0 ser jag om rx-usecs och rx-ramar är inställda. Mer koalescens minskar antalet IRQ:er per sekund och sparar CPU-resurser, men ökar latensen och jitter. Jag justerar försiktigt: små steg, mäter efter varje justering (p95/p99-latens och CPU-belastning). På sändarsidan verkar tx-usecs analogt. Dessutom skalar jag NAPI-beteendet via net.core.netdev_budget och net.core.netdev_budget_usecs, när NET_RX börjar hopa sig i SoftIRQ:er. Om antalet avbrott ökar i /proc/net/softnet_stat, höjer jag budgeten som ett test eller fördelar RX-köerna mer konsekvent; om systemlatensen blir ett problem, skruvar jag ner den igen. Jag beaktar GRO/LRO och TSO/GSO i samspel: Överdriven aggregering sänker IRQ-belastningen, men kan orsaka latensspikar – jag jämnar ut dem med applikationsprofilen.
Läsa SoftIRQ:er på ett transparent sätt
Förutom HardIRQ:er bestämmer jag belastningen i SoftIRQ:er. Med cat /proc/softirqs Jag observerar NET_RX och NET_TX per CPU; om vissa kolumner dominerar hamnar för mycket arbete där i ksoftirqd-trådar. En top -H visa mig snabbt vilka ksoftirqd/N Kärnorna belastar. Jag mäter djupare med perf top eller korta perf rekord Körs för att identifiera flaskhalsar i drivrutinen eller stackbearbetningen. Om ksoftirqd-trådar aktiveras (istället för omedelbar bearbetning i IRQ-kontexten) ökar ofta latensen avsevärt; jag åtgärdar detta med bättre köfördelning, större NAPI-budget eller målinriktad CPU-pinning av de berörda ksoftirqd-trådarna via taskset -pc. Viktigt: Jag dokumenterar dessa justeringar eftersom de har en subtil inverkan och jag i tveksamma fall snabbt behöver kunna återgå till tidigare versioner.
Att använda SMT/Hyper-Threading och topologi på rätt sätt
När SMT är aktiverat delar jag en fysisk kärna med två logiska CPU:er. Jag kontrollerar syskonrelationerna via lscpu -e och /sys/devices/system/cpu/cpuX/topology/thread_siblings_list. För latenskritiska vägar undviker jag att placera app-tråden och tillhörande IRQ på samma fysiska kärna (olika SMT-trådar); de konkurrerar om exekveringsenheter och cacheminnen. Jag föredrar kombinationer där t.ex. en app-tråd körs på CPU2 och den tillhörande RX-kön på CPU3 (annan fysisk kärna, samma NUMA-nod). Om SMT stör stabiliteten planerar jag istället med färre, men exklusiva fysiska kärnor och slipper oroliga Störningar.
Virtualisering: KVM, vhost och SR-IOV
I virtualiserade miljöer betraktar jag värden och gästen separat. På värden fördelar jag fysiska NIC-IRQ:er på ett ordnat sätt över kärnorna i den aktuella NUMA-noden. Om gästen använder virtio-net uppstår ytterligare IRQ:er för vhost-trådar; jag identifierar dem i /proc/avbrott och kopplar vhost-arbetare konsekvent till köerna för det fysiska nätverkskortet. På gästnivå ställer jag också in RSS/XPS och IRQ-affiniteter, förutsatt att virtio-drivrutinen tillhandahåller flera köer. Vid SR-IOV lönar det sig att tilldela varje gäst en eller flera VF:er med egna MSI-X-vektorer och att pina dessa i gästen; isoleringen förbättrar latensen och förutsägbarheten. Jag följer ett tydligt schema: gästens vCPU:er på dedikerade pCPU:er, tillhörande IRQ:er på närliggande kärnor, och att inte blanda emulator-/vhost-trådar med beräkningsintensiva app-trådar – på så sätt förblir datavägen planeringsbar.
CPU-frekvens, C-lägen och NOHZ-inställningar
IRQ-fördröjningarna påverkas negativt när kärnorna går in i djupa C-tillstånd eller klockas aggressivt. För känsliga arbetsbelastningar ställer jag in CPU-regulatorn på prestanda (cpupower frequency‑set -g performance) och minskar djupa C-tillstånd via start- eller drivrutinsinställningar för att begränsa uppvakningstiderna. På hårt belastade servrar ger detta ofta bättre resultat än någon finjustering av affiniteter. I mycket krävande latensprofiler kompletterar jag nohz_full= och rcu_nocbs= för isolerade kärnor, så att tick-timern och RCU-callback-funktionerna inte stör varandra; jag definierar medvetet housekeeping-CPU:erna separat. Dessa ingrepp testar jag dock separat, eftersom de kan ha sidoeffekter på schemaläggningen och energiförbrukningen. Det viktigaste är fortfarande att noggrant jämföra mätvärdena före och efter ändringen, annars går jag vilse i Optimeringar i mörkret.
Systemd, Cgroups och app-isolering
Förutom IRQ-pinning separerar jag app-trådar med Cgroups och systemd-affinity. Via CPU-affinitet = I Unit-filer och CPU-kontrollerna (cgroup v2) tilldelar jag tjänster fasta kärnor. På så sätt förhindrar jag att trådar från schemaläggaren hamnar på de CPU:er som jag har avsatt för IRQ:er. I containermiljöer ställer jag in cpuset.cpus och kontrollera cpuset.cpus.effective, så att löftena om resurser verkligen infrias. Viktigt: IRQBALANCE_BANNED_CPUS styr endast där irqbalance inte fördelar; kärntrådar som ksoftirqd följer fortfarande schemaläggaren. För strikt isolering behöver jag alltså en kombination av IRQ-affiniteter, tjänsternas CPU-affinitet och, vid behov, isolerade kärnor. På så sätt förblir datavägen och applikationen tydligt åtskilda och Last blandas inte okontrollerat.
Vanliga fel och åtgärder
Jag inaktiverar aldrig irqbalance generellt utan att känna till belastningsmönstren; annars samlas IRQ:erna snabbt på ett fåtal kärnor. Det är lika olämpligt att öppna alla kärnor för alla IRQ:er, trots att känsliga trådar är exklusiva Resurser behöver. Ett annat misstag: att inte testa ändringar isolerat och inte mäta effekterna; då förblir det oklart vad som faktiskt hjälper. Jag tar även hänsyn till Hyper-Threading-par: app-tråden och tillhörande IRQ bör helst inte dela samma fysiska kärna. Jag dokumenterar varje steg och skapar återställningspunkter så att jag snabbt kan återgå till den senaste bra Återgå till konfigurationen.
Checklista för serverhantering
Jag börjar alltid med en utgångspunkt: aktivera irqbalance, registrera systembelastningen, övervaka /proc/interrupts och mäta latenser; först därefter justerar jag inställningarna. I det andra steget avslutar jag med IRQBALANCE_BANNED_CPUS väljer ut de kärnor som ska reserveras för app-trådar; på så sätt förhindrar jag onödiga IRQ-avbrott. Därefter kopplar jag bort kritiska IRQ:er via smp_affinity på ett fåtal, väl valda kärnor och ser till att hålla NUMA-närheten. Därefter kontrollerar jag RSS/RPS/RFS och XPS samt NIC:s avlastningsalternativ för att fördela arbetet på ett lämpligt sätt. Slutligen testar jag under produktionsbelastning, jämför mätvärden och behåller endast de ändringar som bevisligen arbete.
Konfigurationsfiler och systemd-kommandon
Jag aktiverar tjänsten med systemctl enable --now irqbalance och kontrollera med systemctl status irqbalance löptiden; så ställer jag in Service säkert klart. I /etc/sysconfig/irqbalance eller . /etc/default/irqbalance jag sätter IRQBALANCE_BANNED_CPUS samt som tillval IRQBALANCE_BANNED_IRQS. Jag tar med ändringarna i systemctl restart irqbalance och följ samtidigt mätarna i /proc/avbrott. Vid testning använder jag irqbalances ”Foreground”-läge för att följa besluten i realtid. Först när jag förstår beteendet skriver jag in justeringarna permanent i Konfiguration.
När jag inaktiverar irqbalance
I realtidsmiljöer eller vid extremt latenskänsliga tillämpningar stoppar jag irqbalance och tilldelar IRQ:er statiskt, så att ingen omfördelning stör. Jag isolerar kärnorna för dessa arbetsbelastningar och låter trafik-IRQ:er medvetet köras på andra kärnor; på så sätt förblir applikationstrådar planeringsbar. Även i strikt separerade tenant-miljöer är denna metod värdefull, eftersom jag därmed minskar störningar mellan virtuella maskiner eller containrar. Om det dyker upp drivrutiner som fungerar sämre med den automatiska inställningen utesluter jag deras IRQ:er via en förbudslista. Så snart belastningsmönstren blir mer varierande igen aktiverar jag irqbalance på nytt och kontrollerar effekten med nya Uppmätta värden.
Kortfattat sammanfattat
Jag börjar med irqbalance, mäter effekten och justerar selektivt istället för att blint ingripa överallt; på så sätt behåller jag helhetsbilden av systemet och Öppenhet. För känsliga arbetsbelastningar tilldelar jag lämpliga IRQ:er, isolerar kärnor för applikationer och tar hänsyn till NUMA-närhet. Med hjälp av banned-masker styr jag var irqbalance får verka och förhindrar oönskade förflyttningar. Jag kontrollerar regelbundet /proc/avbrott, latens och genomströmning, så att ändringarna kan underbyggas med tillförlitliga data. Den som går tillväga på detta sätt utnyttjar IRQ Balances fulla potential och håller servrarna märkbart stabila under nätverksbelastning reaktiv.
