Ga naar de inhoud 
CPU interrupts bepalen hoe snel mijn server reageert op netwerkpakketten, opslaggebeurtenissen en timers - verkeerd gedistribueerde of te frequente interrupts vertragen applicaties meetbaar. Een schone server voor het afhandelen van interrupts vermindert contextwisselingen, verlaagt latenties en stabiliseert reactietijden tijdens piekbelastingen.
Centrale punten
Ik zal de volgende belangrijke aspecten samenvatten voordat ik in detail ga:
- Onderbrekingsbelasting begrijpen: Wanneer procentuele waarden kritisch worden
- Parallellisme manage: Gelijktijdige interrupts en worst-case latenties
- MSI-X gebruiken: Meer nieuws, betere distributie
- RSS & Affiniteit: NIC interrupts op cores plaatsen
- Controle oprichten: Lees getallen, handel doelgericht
Wat veroorzaakt CPU interrupts op servers
Een interrupt is een Signaal, die de CPU onmiddellijk uit zijn huidige taak haalt en een handler start. Netwerkkaarten melden nieuwe pakketten, opslagcontrollers signaleren voltooide I/O, timers triggeren klokken - elk van deze interrupts kost CPU-tijd. Bij hoge activiteit tellen deze gebeurtenissen op tot veel context-switches en cache misses. Ik houd daarom in de gaten hoe vaak en hoe lang de CPU in de kernel bezig is met ISRs en DPCs. Als je deze dynamiek begrijpt, kun je de reactietijden betrouwbaar regelen en applicaties merkbaar soepeler laten draaien.
Waarom hoge interrupttijden prestaties kosten
In gezonde omgevingen zijn systeemonderbrekingen meestal tussen 0,1-2% CPU is 3-7% op korte termijn mogelijk. Als de interrupttijd regelmatig boven 5-10% blijft, zit er vaak een driverprobleem, defecte hardware of onjuiste tuning achter. Vanaf 30% wordt het serieus, voorbij 50% dreigt het gevaar van Knelpunten en trage responstijden. Applicaties verliezen doorvoer, latenties verspringen en de voorspelbaarheid lijdt eronder. Ik controleer dan eerst driverversies, firmware, affiniteiten en de moderatie van interrupts op de NIC's.
Gelijktijdige interrupts: latenties begrijpen
Een enkele interrupt blijft zelden een Probleem; Het wordt moeilijk wanneer verschillende gebeurtenissen botsen. Als een interrupt met hoge prioriteit optreedt tijdens een interrupt met lage prioriteit, dan wordt de verwerking ervan verlengd door verdere interrupties. Een voorbeeld: Als het pad met hoge prioriteit 75 cycli vereist en het pad met lage prioriteit 50, dan neemt de latentie van het pad met lage prioriteit gemakkelijk toe tot 125 cycli - verdere overlappingen verhogen de latentie. In het ergste geval-latentie neemt snel toe. Dit gedrag maakt systemen onvoorspelbaar. Daarom plan ik core affiniteiten en prioriteiten zo dat hotpaths elkaar niet blokkeren.
MSI en MSI-X in het dagelijks leven
Moderne hosts gebruiken MSI of MSI-X, in plaats van klassieke lijnsignalen (IRQ lijnen) te versturen. MSI verzendt het bericht als een schrijven naar het geheugen, waardoor de latentie en de gevoeligheid voor interferentie wordt verminderd. MSI-X breidt het concept uit: meer berichten, aparte wachtrijen, nauwkeuriger verdeling over cores. Dit vermindert interrupt botsingen en verbetert de Schalen met hoge doorvoer. Ik schakel MSI-X in voor NIC's en NVMe-controllers zolang de stuurprogramma's en firmware dit stabiel ondersteunen.
| mechanisme | Max. Berichten | aanspreken | Distributie naar kernen | Typisch effect |
|---|---|---|---|---|
| Legacy IRQ | 1 per apparaat/lijn | Lijnsignaal | Beperkt | Hoger Latency, meer botsingen |
| MSI | Tot ~32 | Geheugen schrijven (16-bit) | Goed | Minder overhead, stabielere paden |
| MSI-X | Tot 2048 | Geheugen schrijven (32-bits) | Zeer goed | Fijner Distributie, hoger parallellisme |
DMA, DPC's en het juiste gegevenspad
Met DMA kunnen apparaten gegevens rechtstreeks opslaan in de Geheugen De CPU triggert alleen verwerkingsroutines. Dit bespaart interrupts omdat er minder tussentoestanden gesignaleerd hoeven te worden. Ik zorg ervoor dat DPC's het eigenlijke werk bundelen in plaats van teveel te doen in de ISR. Dit houdt de tijd in het kritieke gedeelte kort en de Latency voorspelbaarder. In het algemeen wint de CPU meer tijd voor de applicatielogica.
RSS en CPU affiniteit specifiek configureren
Receive Side Scaling verdeelt netwerkwachtrijen en hun interrupts over meerdere kernen. Ik bind elke wachtrij inclusief interrupt, DPC en gebruikers thread aan dezelfde core of core cluster om cross-core wakes te voorkomen. Als verschillende cores betrokken zijn bij een flow, nemen cache misses en context switches toe. Een gestructureerd affiniteitsplan voorkomt dergelijke wrijvingsverliezen aanzienlijk. Als u dieper wilt graven, kunt u een compact CPU-affiniteit-Overzicht voor hostingopstellingen.
Opslagonderbrekingen en I/O-paden onschadelijk maken
Opslag genereert ook veel Onderbrekingen, vooral met veel kleine IOPS. Ik gebruik MSI-X op NVMe-controllers en wijs wachtrijen toe aan vaste kernen zodat invoer en uitvoer lokaal blijven. Daarnaast is een geschikte I/O-planner, om de belasting per wachtrij af te vlakken. Deadline, BFQ of MQ varianten reageren heel verschillend afhankelijk van de werklast. Als je hier goed test, verminder je jitter en verhoog je de Doorvoer.
Netwerkstormen, SYN-overstromingen en onderbrekingsmatiging
Plotselinge overstromingen van pakketten drijven de ISR-snelheid en ontnemen de CPU de adem. Ik activeer interrupt moderatie op de NIC zodat pakketten in redelijke bursts aankomen zonder latency pieken te genereren. Voor DoS scenario's is een veerkrachtige SYN waterkering de verbindingstabel in een vroeg stadium. Tegelijkertijd meet ik of de moderatie zelf te langzaam reageert - dan pas ik de waarden aan. Het doel is om een soepele pakketstroom te krijgen die DPC's gelijkmatig verdeelt. voert.
Monitoren: cijfers lezen en ernaar handelen
Ik begin met een paar, duidelijke MetriekCPU-totaalgebruik, interrupttijd, DPC-tijd, contextschakeling en processorwachtrij. Als de CPU gewoonlijk onder 50% blijft, reageer ik rustig; bij 50-80% observeer ik pieken en hotspots; boven 80% plan ik schaling of tuning. Als de onderbrekingstijd boven 30% komt, controleer ik het stuurprogramma, de firmware en de affiniteiten. Een latentiecontrole voor audio/video laat indirect zien hoe deterministisch de kernel reageert. Belangrijk: ik verander slechts één Variabele per test en meet dan opnieuw.
NUMA topologie en PCIe lokaliteit
Op multi-socket hosts beslis ik altijd over interrupt affiniteiten in de context van de NUMA-topologie. Een NIC of een NVMe controller is fysiek verbonden met een PCIe root complex en dus met een NUMA knooppunt. Als ik de wachtrijen en hun interrupts instel op ver weg cores, reizen gegevens via UPI/QPI links - latencies nemen toe, bandbreedte neemt af. Ik controleer daarom aan welk NUMA-knooppunt een apparaat is toegewezen, koppel de wachtrijen aan lokale kernen en zorg ervoor dat de bijbehorende gebruikersthreads hetzelfde knooppunt gebruiken. Op Windows let ik op processorgroepen en de apparaatinstelling voor het geprefereerde NUMA-knooppunt; op Linux koppel ik IRQ's, softirq's en applicatie-threads consequent aan het lokale knooppunt. Het resultaat: minder verkeer tussen knooppunten, stabieler Jitter-waarden en berekenbare worst-case latenties.
Offloads, NAPI en coalescing correct gebruiken
Offloads zijn krachtige hefbomen tegen interrupt-overstromingen, maar moeten worden gebruikt om Werkbelasting fit. Grof samengevat: TSO/GSO verplaatsen de segmentatie naar de NIC, LRO/GRO vatten binnenkomende segmenten samen, RSC op de host heeft een vergelijkbaar effect als LRO. Voor bulkoverdrachten (back-up, replicatie) verhogen deze eigenschappen de doorvoer en verlagen ze de ISR-snelheid aanzienlijk. Voor latentiekritische stromen (RPC's, handel, VoIP) kunnen grote aggregaties echter een negatieve impact hebben op de ISR-snelheid. Reactietijden uitbreiden. Ik kies daarom voor gematigde instellingen: GRO ja, maar overdrijf het niet; LRO alleen als er geen mid-path apparaten of firewalls problemen veroorzaken; laat TSO/GSO als regel actief.
NAPI op Linux schakelt vanaf het laden over van pure interruptmodus naar pollmodus. Dit vlakt pieken af en houdt de CPU bezig in het DPC pad in plaats van duizenden korte ISR's te triggeren. Samen met Matiging onderbreken (coalescing), wordt er een plan gemaakt: korte timers voor interactieve profielen, langere timers voor bulk. Ik test intervallen in stappen van microseconden, observeer druppels, ringvullingsniveaus en latenties om de 'sweet spot' te vinden. In de opslagstapel leveren analoge stelschroeven (wachtrijdiepte, NCQ, blk-mq optimalisaties) hetzelfde effect op: minder staccato, meer Efficiëntie.
IRQ-balancering vs. statische pinning
Automatische IRQ-balancering verdeelt de belasting acceptabel, maar niet perfect. In homogene webomgevingen laat ik het vaak draaien en controleer ik alleen de hotspots. In latentiekritieke of asymmetrische opstellingen Statisch vastzetten superieur: Ik definieer vaste CPU sets voor elke wachtrij en apparaat, houd ze consistent via reboots en minimaliseer de migratie van softirqs. Daarnaast reserveer ik „huishoudelijke“ cores voor achtergrondwerk (timers, Kthreads) zodat prestatiecores vrij blijven. Op Windows gebruik ik specifiek interruptbesturing en affiniteitsmaskers voor elke wachtrij; op Linux werk ik met per-IRQ affiniteit en Softirq-besturing. Het motto: zoveel automatisering als nodig, zoveel Determinisme mogelijk.
Virtualisatie en SR-IOV/virtio
Extra kosten ontstaan in VM's: Virtuele interrupts betekenen VM verlaat, planningsvertragingen en gedeelde wachtrijen. Ik koppel I/O-intensieve vCPU's aan geschikte pCPU's, vermijd overcommit op I/O-hosts en scheid dataplane threads van beheerbelasting. Waar mogelijk gebruik ik SR-IOVVirtuele functies brengen MSI-X naar de gast-VM en verminderen de belasting van het hypervisorpad. Voor generieke werklasten levert virtio met vhost-acceleratie solide resultaten; in scenario's met hoge doorvoer breng ik wachtrijen 1:1 in kaart voor vCPU's en houd ik affiniteiten consistent van gast naar host. Belangrijk: Dezelfde regels voor RSS, coalescing en NUMA gelden ook in VM's - alleen de Transparantie is lager, dus ik meet nauwkeuriger.
Energiebeheer en deterministische latenties
Energiebesparende functies zijn goed voor de balans, maar slecht voor de harde kern Latency-budgetten. Diepe C-states verlengen de wektijd, agressieve frequentieveranderingen veroorzaken jitter. Op hosts met strikte SLO's stel ik prestatieprofielen in, beperk ik diepe pakket-C-states en sta ik turbo alleen toe als de thermische reserve groot genoeg is. Timerbeslissingen (hoge-resolutie timers vs. lagere interruptfrequentie) beïnvloeden ook de hoeveelheid en snelheid van kernelwerk. In bijna-realtime opstellingen helpen tickless modi en geïsoleerde kernen: applicatie-threads op geïsoleerde kernen, systeemwerk op speciale „huishoudelijke“ kernen - zodat de kritieke Hotpath vrij van storende branden.
Tools en meetmethodologie per OS
Ik houd mijn Diagnostische keten slank en reproduceerbaar. Op Linux begin ik met /proc/interrupts en /proc/softirqs, controleer per-queue counters via ethtool en kijk naar de coalescing en offload instellingen. mpstat, vmstat en sar laten macrotrends zien; perf legt hotspots bloot in ISRs/DPCs. Ik correleer pakket- en druppeltellers met kerneltijden en flowmetriek. Op Windows geven prestatie-indicatoren voor interrupt/DPC-tijd, interrupts/sec en DPCs/sec een duidelijk beeld; traces laten zien welke stuurprogramma's de klok zetten. Belangrijk is de gemeenschappelijke TijdschaalIk log alles gesynchroniseerd zodat pieken, dalen en latentiesprongen overeenkomen.
Draaiboek en antipatroon voor probleemoplossing
Mijn procedure is consequent: eerst Let op, dan een hypothese, dan een verandering. Typische oorzaken: een wachtrij of een apparaat met een escalerende ISR rate, defecte firmware, coalescing waarden die te hoog zijn (hard systeem) of te laag (ISR storm), offloads die te groot bundelen, of threads die wachtrijen over NUMA nodes trekken. Ik isoleer het getroffen apparaat, test conservatieve standaardinstellingen, pas stuurprogramma's/BIOS aan en verdeel de belasting netjes. Anti-patroon: alles tegelijk verplaatsen, rommelige rollbacks, geen baseline of metingen zonder context. Als u voortdurend een Variabele na elkaar, zul je snel een stabiele configuratie krijgen.
Blauwdrukken voor 10/25/100G hosts en NVMe
Voor 10G NIC's bereken ik 4-8 RSS-wachtrijen, afhankelijk van de CPU-generatie en het pakketprofiel. Ik begin matig te coalescen (bijvoorbeeld lage tweecijferige microseconden), GRO aan, LRO voorzichtig. Bij 25G schaal ik naar 8-16 wachtrijen en houd de affiniteit strikt NUMA-lokaal. Vanaf 40/100G wordt de wachtrijarchitectuur de KerntaakVeel wachtrijen, schone toewijzing per core, actieve offloads, NAPI treedt in werking onder belasting. Voor NVMe-opslag breng ik ten minste één wachtrij per core in kaart en houd ik de wachtrijdiepte geschikt voor de werklast - kleine I/O's hebben baat bij meer parallellisme, grote sequentiële overdrachten bij een stabiel coalesceringsbeleid en een scheduler die bursts afvlakt. Het doel blijft hetzelfde: constante latencies, geen hete cores, geen overvolle ringen.
Praktische checklist voor snel succes
Ik update eerst Bestuurders en BIOS/firmware, omdat foutieve toestanden vaak de interruptbelasting opdrijven. Daarna schakel ik, indien mogelijk, over naar MSI-X en verdeel wachtrijen netjes over cores. Ik stel RSS in zodat de stroomaffiniteiten correct zijn en de hotpaths consistent blijven. Op de NIC pas ik de moderatie aan het verkeersprofiel aan en observeer het effect op latencies. Als ik uitschieters blijf vinden, zoek ik naar defecte hardware, verkeerde opties of probleemapparaten met behulp van de uitsluitingsprocedure en een apart Profilering.
Kosten en baten realistisch inschatten
Niet elk systeem heeft het maximale nodig Fijnafstemming. Ik geef prioriteit aan hosts met een hoge pakketbelasting, veel kleine IOPS of strakke latency specificaties. Een paar uur afstellen loont daar enorm omdat minder interrupt-overhead direct CPU vrijmaakt voor de applicatie. Op niet-kritieke servers is een degelijke basisconfiguratie met de nieuwste stuurprogramma's en MSI-X voldoende. Ik laat me leiden door de gemeten waarden, niet door onderbuikgevoelens of Veronderstellingen.
Samenvatting: Wat ik verpak in dagelijks onderhoud
Ik observeer consequent Onderbreek- en DPC-tijden, houd stuurprogramma's en firmware up-to-date en gebruik MSI-X waar mogelijk. Ik plan RSS en affiniteiten per werklast zodat flows, DPC's en threads lokaal blijven. Ik pas de NIC moderatie aan op patronen in het verkeer, verdeel opslagwachtrijen netjes en gebruik geschikte I/O-paden. Als de monitoring uitschieters laat zien, werk ik dwars door de drivers, hardware en configuratie heen. Op deze manier blijft de server die interrupts afhandelt voorspelbaar en draaien mijn werklasten stabiel. Prestaties.
