Interrupt samenvoegen bundelt meerdere inkomende pakketten in een enkele hardware interrupt, waardoor de CPU minder wordt belast en de doorvoer toeneemt. Ik laat zien hoe je timings, thresholds en NIC functies zoals RSS en RSC kunt afstemmen om latency, jitter en Doorvoer afhankelijk van de werklast.
Centrale punten
OverzichtDe volgende kernaspecten leiden je op een gestructureerde manier door technologie, afstemming en praktijk.
- CPU ontladenMinder interrupts, hogere verwerkingscapaciteit.
- Afruil latentieMilliseconden tegen stabiliteit en pps.
- NIC-afstemmingRSS, RSC, MTU en BIOS energieprofielen.
- OS instellenethtool, RSC/RSS, wachtrijen voor bestuurders.
- Controlepps, interrupts/s, p99 latentie.
Interrupt coalescing kort uitgelegd
Coalescing betekent dat de netwerkkaart binnenkomende pakketten verzamelt en alleen een interrupt activeert als er genoeg werk is of als een timer afloopt. Op deze manier verminder ik het aantal interrupts aanzienlijk en verplaats ik delen van de pakketverwerking in de NIC, waardoor de CPU minder wordt belast. Op Windows servers helpt Receive Segment Coalescing (RSC) door verschillende segmenten samen te voegen tot grotere blokken en de verwerkingskosten te verlagen. Op Linux regel ik de aggregatie via rx-usecs (tijd) en rx-frames (pakketten), afhankelijk van de karakteristieken van de stroom en de beoogde latentie. Deze aanpak vermindert de overhead, houdt cores vrij en stabiliseert de doorvoer bij zwaar verkeer. Het bewuste compromis blijft belangrijk: elke samenvatting voegt een kleine wachttijd toe, die ik strikt beperk voor latency-kritische stromen.
Mechanica: Timings, FIFO en drempels
NIC's inkomende frames in een FIFO wachtrij houden en interrupts triggeren op basis van twee criteria: na x ontvangen frames of na y microseconden. Ik stel kleine tijdvensters in voor diensten met lage latentie en verhoog ze voor stromen met hoge doorvoer en grote bursts. Eén wachtrij per ontvangstwachtrij verbetert parallellisatie, terwijl interrupt moderatie core veranderingen vermindert en beter gebruik maakt van de cache. Te hoge rx-usecs voegen echter vertraging toe; te lage waarden genereren interrupt stormen en drukken de cache naar beneden. Doorvoer. Daarom balanceer ik de time-out en pakketlimiet op basis van de MTU, framegrootte en het aandeel kleine pakketten.
Adaptieve moderatie en burst-detectie
Adaptief samenvoegen past dynamisch tijd- en pakketvensters aan de huidige belasting aan. Ik gebruik het wanneer belastingsprofielen sterk fluctueren: bij een lage pps-snelheid blijven de vensters klein (lage latency); als de pps-snelheid toeneemt, worden ze breder (waardoor de CPU minder wordt belast). Het voordeel hangt af van de driver: sommige NIC's detecteren bursts en verhogen de rx-usecs op korte termijn, andere werken met vaste niveaus. Ik controleer de Stabiliteit van de p99 latentie met adaptatie geactiveerd; grillige curven duiden op te agressieve sprongen. Voor deterministische diensten geef ik de voorkeur aan het instellen van statische, fijn geselecteerde drempels, terwijl ik adaptieve modi in bulkoperatie toesta zolang er geen druppels op de ring zijn.
Doorvoer versus latentie: het controleerbare compromis
Latency neemt af als ik coalescing uitschakel, maar de CPU werkt dan aanzienlijk meer en schaalt slechter onder belasting. Voor bestandsoverdracht, streaming of replicatie accepteer ik enige vertraging, omdat dit de stabiliteit en netto doorvoer verhoogt. Voor VoIP, real-time gaming of HFT geef ik de voorkeur aan minimale vertraging en schakel ik moderatie uit. Ik controleer ook de TCP congestiecontrole, omdat algoritmen zoals CUBIC of BBR het gedrag bij pakketverlies, RTT en bursts sterk beïnvloeden. Met nauwkeurig afgestelde timers, RSS en geschikte TCP parameters kan de afweging meetbare optimalisatie.
Samenvoegen van zenden, TSO/GSO/GRO en LRO
Naast RX is de TX coalescing spelen een rol: tx-usecs en tx-frames bundelen uitgaande pakketten, wat contextwisselingen bespaart en de doorvoer van verzendingen stabiliseert. Ik gebruik gematigde tx-usecs om bulkverzendingen af te vlakken, maar houd ze klein als korte reacties (bijv. HTTP API's) snel verzonden moeten worden. Offloads zoals TSO/GSO segmenten vergroten voor verzending en het aantal pakketten verminderen, terwijl GRO/LRO segmenten samenvoegen aan de RX-kant. Ik valideer of GRO/LRO harmoniëren met mijn middleboxes; voor bepaalde firewalls of capture vereisten verminder ik LRO om pakketgrenzen zichtbaar te houden. Al met al combineer ik TX coalescing en offloads op zo'n manier dat PPS wordt gereduceerd en de kernel minder SoftIRQ tijd spendeert zonder de responstijden onnodig op te rekken.
NIC-tuning voor hostingservers
RSS (Receive-Side Scaling) verdeelt inkomende stromen over meerdere cores en voorkomt dat een enkele core een rem wordt. Ik activeer RSS en stel voldoende ontvangstwachtrijen in zodat multi-core CPU's efficiënt werken. RSC vermindert ook de belasting door kleinere segmenten samen te voegen, wat het aantal pakketten in de stack vermindert. Voor hosting workloads combineer ik coalescing met schone MTU selectie, DSCP/QoS prioritering en CPU power profielen in het BIOS, waarbij C-states en deep sleep modes de latency niet verhogen. Ik test de combinaties in belastingspieken en controleer of IRQ affiniteit en queue pinning de cache localiteit behouden. Zo breng ik nic tuning hosting en onderbreek coalescerend netwerk.
NUMA, MSI-X en flow steering
Op multi-socket hosts let ik op NUMA-lidmaatschap: ik koppel ontvangstwachtrijen aan kernen die zich dicht bij het PCIe slot bevinden en plaats geassocieerde werkerthreads op hetzelfde NUMA knooppunt. MSI-X-interrupts bieden verschillende vectoren; ik gebruik er zoveel als zinvol is, zodat elke RX/TX-wachtrij zijn eigen interrupt heeft en lock-retentie wordt verminderd. Daarnaast helpen RPS/RFS/XPS, om stromen naar de „juiste“ kernen te leiden en de toewijzing van verzendingen te regelen. Ik meet L1/L2 miss rates en observeer of cross-core verkeer toeneemt; als dit het geval is, heralloceer ik wachtrijen of verminder ik het aantal wachtrijen om de lokaliteit te vergroten.
Parameters en hun effecten (tabel)
Parameters zoals rx-usecs, rx-frames, RSS-wachtrijen en RSC bepalen of ik liever latentie minimaliseer of doorvoer stabiliseer. Ik begin met conservatieve waarden, meet p99 latentie en interrupts per seconde en verhoog dan voorzichtig de tijdvensters. Kleine stapjes maken het makkelijker om effecten toe te schrijven en verkeerde interpretaties te voorkomen. Als bursts overheersen, verhoog ik de rx-frames iets en controleer ik de jitterverdeling. Voor gemengde werklasten varieer ik voor elk VLAN- of NIC-profiel zodat Stromen met verschillende doelstellingen worden afzonderlijk geoptimaliseerd.
| Parameters | Effect | Risico | Geschikt voor |
|---|---|---|---|
| rx-usecs (tijd) | CPU-Opluchting door vertragingsraam | Meer latentie voor korte stromen | Hoge doorvoer, back-ups, replicatie |
| rx-frames (pakketten) | Combineert kleine pakketten in één Onderbreek samen | Cue-vulling voor uitbarstingen | Veel kleine pakketten, webverkeer |
| RSS-wachtrijen | Geschaalde verwerking over meerdere kernen | Onjuiste pinning verhoogt cross-core verkeer | Multi-core hosts met 10-100 Gbit/s |
| RSC/RSS actief | Minder pakketbelasting in de Stapel | Ongeschikt voor ultralage latentie | Hosting, virtualisatie, opslag |
InterpretatieAls korte stromen domineren, besteed ik het effect uit aan het rx-usecs minimum; voor bulkoverdrachten stel ik hogere waarden in en profiteer ik van een dalende interruptsnelheid. Ik controleer p95/p99 latentie en PPS na elke stap om verkeerde configuraties te voorkomen. Als de belasting toeneemt, controleer ik de zachte IRQ tijden en contextschakelingen om er zeker van te zijn dat CPU tijd stroomt naar waar het echt van nut kan zijn. Een schone IRQ affiniteitsindeling voorkomt rondzwervende interrupts tussen cores en bespaart Cache-hit.
Praktijk: Windows Server en Linux
WindowsIn Apparaatbeheer open ik de eigenschappen van de NIC, selecteer „Geavanceerd“ en pas indien nodig interruptmoderatie, RSS en RSC aan; voor harde low-latency stel ik moderatie in op „Uitgeschakeld“. Ik stel de stroomprofielen in op hoge prestaties zodat C-States de responstijd niet verhogen. LinuxIk gebruik ethtool om rx-usecs/rx-frames aan te passen en gebruik ethtool -S om de IRQ en error counters te controleren; irqbalance of expliciete affinity pinning wijst wachtrijen toe aan de cores. Voor hele kleine pakketten experimenteer ik met GRO/LRO en controleer ik of het gebruikerspad of het kernelpad de bottleneck is. Ik ga dieper in op dit onderwerp in mijn gids voor CPU interrupts optimaliseren, waarin meetbare stappen en tegencontroles worden beschreven.
Virtualisatie en cloud: SR-IOV, vSwitch en vRSS
In gevirtualiseerde omgevingen is de Pad van de pakketten de optimale instelling. Met SR-IOV VF's omzeilen de overhead van de vSwitch; ik stel coalescing direct in op de PF/VF en zorg ervoor dat de gast en host hetzelfde beleid hebben. In vSwitch scenario's (Hyper-V, Open vSwitch) zijn er extra wachtrijen en schedulers nodig; vRSS verdeelt de belasting binnen de VM over meerdere vCPU's. Ik meet of coalescing plaatsvindt in de host of in de VM en voorkom dubbele moderatie met te grote vensters. Voor NFV/DPDK werklasten wordt het werk verplaatst naar de gebruikersruimte; ik pas de polling budgetten daar aan en houd kernel coalescing conservatief om de metingen niet te vervalsen.
Prestatiemeting en telemetrie
Meting zorgt voor elke optimalisatie, dus ik houd pps, bytes/s, interrupts/s, SoftIRQ tijden, drops en wachtrijlengte bij. Ik vergelijk p50/p95/p99 latency en let op burstgedrag, omdat gemiddelde waarden scherpe uitschieters maskeren. Voor HTTP/2/3 meet ik verbindingsdichtheid, verzoeksnelheid en CPU-tijd per verzoek om de neveneffecten van coalescing te herkennen. Opslagknooppunten profiteren als ik kijk naar iowait, IRQ-belasting en netwerklatentie samen, omdat knelpunten de neiging hebben om te migreren tussen stacklagen. Dashboards met gebeurtenissen en implementatietijden helpen om duidelijk tuningstappen toe te wijzen en regressies onmiddellijk te stoppen.
Tijdkritische protocollen en hardwaretimestamps
Voor protocollen met nauwkeurige tijdmeting (bijvoorbeeld PTP), controleer ik of coalescing de nauwkeurigheid van de tijdstempels beïnvloedt. Sommige NIC's bieden hardware timestamps die worden ingesteld voordat de coalescing plaatsvindt - ideaal voor de meetnauwkeurigheid. In zulke gevallen schakel ik LRO/GRO uit en beperk ik rx-usecs tot een minimum zodat latentievarianten de tijdsynchronisatie niet verstoren. Voor deterministische netwerken (TSN) houd ik energiebesparende modi vlak, stel ik QoS strikt in en bevestig ik dat er geen wachtrijen zijn die overflows genereren die de klokstabiliteit in gevaar brengen.
Werklastprofielen: Wanneer activeren, wanneer niet?
Hoge doorvoerBack-ups, CDN origin, objectopslag en VM-replicatie hebben veel baat bij coalescing omdat de CPU minder wordt verstoord. Webhosting met veel kleine requests heeft gematigde waarden nodig, gecombineerd met RSS en goede cache localiteit. Virtuele omgevingen winnen als ik slimme standaardwaarden per vNIC instel en lawaaierige buren isoleer. Voor VoIP, gaming of real-time telemetrie schakel ik moderatie uit of stel ik zeer strakke timers in. Metingen volgens het verkeersprofiel zijn verplicht, omdat 10 Gbit/s bulkverkeer zich anders gedraagt dan 1 Gbit/s API-verkeer.
Ringgroottes, buffers en druppelgedrag
Naast timers Ringmaten (RX/TX descriptors) om betrouwbaarheid tijdens bursts te garanderen. Ik verhoog RX descriptors gematigd wanneer korte pieken drops veroorzaken, waarbij ik let op de geheugenvoetafdruk en cache fitness. Te grote ringen verbergen problemen, maar verlengen de wachttijden in de pijplijn. Ik controleer „rx_no_buffer“, „dropped“ en „overruns“ in statistiektellers en vergelijk drempelwaarden met typische burst-lengtes. Een fijn uitgebalanceerde combinatie van rx-frames, rx-usecs en ringgrootte voorkomt Uitbarstingen leiden tot verliezen of jitterpieken.
Jitter, pakketverlies en burstverwerking
Jitter treedt op wanneer het coalescing-venster en het burst-patroon ongunstig op elkaar inwerken; ik kan dit herkennen aan brede latentieverdelingen. Kleine timersprongen vlakken vaak de p99-curve af zonder de doorvoer zichtbaar te verminderen. Als de NIC onder belasting wegvalt, stel ik minder agressieve waarden in en controleer ik de wachtrijdiepte en driverstatussen. Voor websites helpt het om het volgende te analyseren Netwerk jitter, om render blocking verzoeken en TLS handshakes planbaar te maken. Tot slot controleer ik of het QoS-beleid de prioriteitsklassen netjes scheidt en zo voorkomt dat kritieke Stromen prefereren.
Checklist voor praktische afstemming
Start met basislijn: Ik registreer latency, pps, interrupts/s en CPU-profiel voor elke verandering. Dan activeer ik RSS/RSC, stel gematigde coalescing waarden in en meet p50/p95/p99 opnieuw. Dan verhoog ik rx-usecs in kleine stapjes totdat jitter of p99 latency toeneemt en rol terug naar het laatste goede punt. Ik wijs wachtrijen toe aan vaste cores en monitor cache misses; als cross-core verkeer toeneemt, pas ik de affiniteit aan. Ik documenteer elke verandering kort en vergelijk belastingspieken zodat de Stabiliteit lijdt niet in het geheim.
Voorbeeld startwaarden volgens verbindingssnelheid
- 1 Gbit/s: rx-usecs 25-50, rx-frames 8-16, tx-usecs 25-50; weinig RSS-wachtrijen (2-4), focus op latentie.
- 10 Gbit/s: rx-usecs 50-100, rx-frames 16-32, tx-usecs 50-100; 4-8 RSS wachtrijen, GRO aan, LRO selectief.
- 25/40 Gbit/s: rx-usecs 75-150, rx-frames 32-64, tx-usecs 75-150; 8-16 keuen, NUMA pinning strikt, RSC/RSS actief.
- 100 Gbit/s: rx-usecs 100-200, rx-frames 64-128, tx-usecs 100-200; 16-32 keuen, MSI-X volledig benutten, ringgroottes matig vergroten.
TipDit zijn conservatieve uitgangspunten. Ik optimaliseer langs de p99 latency en drops en houd rekening met pakketgroottes (MTU 1500 vs. Jumbo), flowmix en CPU-topologie.
Kosten, energie en duurzaamheid
Energie vermindert als ik de interrupt rate druk omdat de CPU minder context switches en wake-ups uitvoert. In datacenters telt dit op over veel hosts en verlaagt het merkbaar de stroom- en koelingskosten. Een upgrade naar moderne 10/25/40/100G NIC's met goede moderatie kost meestal een paar honderd euro, maar verdient zichzelf vaak snel terug dankzij de lagere CPU-tijd per byte. Ik houd er rekening mee of licenties, driveronderhoud en monitoring al aanwezig zijn om de gebruikskosten laag te houden. Voor SLA-kritische diensten is een conservatief venster de moeite waard, dat Jitter beperkt en beveiligt de gebruikerservaring.
Probleemoplossing en antipatroon
Metriek tonen Stormen onderbreken, Ik verlaag RSS-wachtrijen of verhoog rx-usecs iets. Voor „wiebelende“ latentiecurves schakel ik bij wijze van test adaptieve moderatie uit. Als er drops optreden ondanks hoge CPU-reserves, controleer ik ringgroottes, firmwareversie en PCIe link state power management. Een klassieker: zeer hoge coalescing + GRO/LRO actief maskeert pakketverliezen in p50, terwijl p99 lijdt - ik herbalanceer dan rx-frames en verkort rx-usecs. Met multi-tenant hosts veroorzaken „luidruchtige buren“ een ongelijk verdeelde IRQ-belasting; ik gebruik harde affiniteitsmaskers en QoS-klassen om kritieke IRQ's te vermijden. Stromen om ze te beschermen. Belangrijk: Rol wijzigingen altijd afzonderlijk uit en test ze tegen identieke belastingsprofielen om oorzaak en gevolg duidelijk van elkaar te scheiden.
Samenvatting: Sneller, soepeler, voorspelbaarder
KernideeInterrupt coalescing vermindert interferentie, verdeelt het werk slimmer en verhoogt de netto doorvoer zolang ik timers en pakketlimieten doelgericht instel. Voor diensten met hoge doorvoer kies ik ruimere vensters, voor real-time diensten minimaliseer of deactiveer ik moderatie. Ik maak volledig gebruik van multi-core CPU's met RSS, RSC, MTU-discipline en schone IRQ affiniteit. Metingen met p95/p99, interrupts/s en SoftIRQ tijden beveiligen elke verandering en voorkomen verkeerde interpretaties. Dus mijn Netwerk Stil onder belasting, reageert snel en levert voorspelbare latenties voor hosting en applicaties.
