Hohe Netzwerk-Last entscheidet sich an der effizienten Verarbeitung von Server IRQ Signalen: Wer Interrupts klug über CPU‑Kerne verteilt, senkt Latenz und verhindert Drops. In diesem Leitfaden zeige ich praxisnah, wie ich IRQ‑Balancing, RSS/RPS und CPU‑Affinity kombiniere, um Hochlast‑Hosting dauerhaft performant zu betreiben.
Zentrale Punkte
- IRQ‑Verteilung verhindert Hotspots auf einzelnen CPU‑Kernen.
- Multi‑Queue plus RSS/RPS parallelisiert die Paketverarbeitung.
- NUMA‑Achtung reduziert Cross‑Node‑Zugriffe und Latenz.
- CPU‑Governor und Thread‑Pinning glätten Reaktionszeiten.
- Monitoring prüft pps, Latenzen, Drops und Kernauslastung.
IRQs knapp erklärt: Warum sie die Netzwerk-Last steuern
Bei jedem eingehenden Paket meldet die Netzwerkkarte per IRQ, dass Arbeit ansteht, sonst müsste der Kernel aktiv pollen. Bleibt die Zuweisung auf einem Kern, steigt dessen Auslastung, während andere Kerne ungenutzt bleiben. Genau dann wachsen Latenzen, die RX‑Ring‑Buffer füllen sich, und Treiber beginnen, Pakete zu verwerfen. Ich verteile Interrupts über passende Kerne, um die Paketabwicklung gleichmäßig und planbar zu halten. So entlaste ich Engpässe, glätte Antwortzeiten und halte Paketverluste in engen Grenzen.
IRQ‑Balancing und CPU‑Affinity unter Linux
Der Dienst irqbalance verteilt Interrupts dynamisch, analysiert Last und verschiebt Affinitäten automatisch über Zeit. Für extreme Lastprofile definiere ich Affinitäten manuell über /proc/irq/<irq>/smp_affinity und binde Queues gezielt an Kerne desselben NUMA‑Nodes. Diese Kombination aus Automatik und Feintuning hilft mir, sowohl Grundlast als auch Spitzen sauber zu bearbeiten. Einen vertiefenden Einstieg zu Interrupt‑Handling und CPU‑Optimierung nutze ich als Gedankenstütze für die Planung. Wichtig bleibt: Ich verknüpfe Hardware‑Topologie, IRQ‑Verteilung und Applikations‑Threads konsequent miteinander.
Multi‑Queue NICs, RSS und RPS praxisnah einsetzen
Moderne NICs liefern mehrere RX/TX‑Queues, jede Queue triggert eigene IRQs, und Receive Side Scaling (RSS) verteilt Flows auf Kerne. Fehlen genügend Hardware‑Queues, ergänze ich im Kernel Receive Packet Steering (RPS) und Transmit Packet Steering (XPS) für zusätzliche Parallelität. Mit ethtool -L ethX combined N gleiche ich die Queue‑Anzahl an die Kernzahl des zugehörigen NUMA‑Nodes an. Ich prüfe mit ethtool -S und nstat, ob Drops, Busy Polls oder hohe pps‑Spitzen auftreten. Für feinere Lastglättung beziehe ich auch Interrupt Coalescing in die Planung ein, damit die NIC nicht zu viele Einzel‑IRQs erzeugt.
Die folgende Tabelle zeigt zentrale Bausteine und typische Kommandos, die ich für ein stimmiges Setup verwende:
| Baustein | Ziel | Beispiel | Hinweis |
|---|---|---|---|
| irqbalance | Automatische Verteilung | systemctl enable --now irqbalance | Startpunkt für gemischte Workloads |
| Affinity | Fixes Pinning | echo mask > /proc/irq/XX/smp_affinity | NUMA‑Zuordnung beachten |
| Queues | Mehr Parallelität | ethtool -L ethX combined N | Auf Node‑Kerne matchen |
| RSS/RPS | Flow‑Verteilung | sysfs: rps_cpus/rps_flow_cnt | Bei wenigen NIC‑Queues sinnvoll |
| XPS | Geordnete TX‑Pfad‑Kerne | sysfs: xps_cpus | Vermeidet Cache‑Thrash |
Automatisches IRQ‑Balancing sinnvoll nutzen
Für gemischte Hosting‑Server reicht oft die Aktivierung von irqbalance, weil der Daemon Lastverschiebungen laufend erkennt. Ich prüfe den Status über systemctl status irqbalance und werfe einen Blick auf /proc/interrupts, um die Verteilung pro Queue und Kern zu sehen. Steigen Latenzen in Peaks, lege ich testweise Kerne fest, die vorrangig Interrupts bearbeiten, und vergleiche Messwerte vor und nach der Änderung. Dabei halte ich die Konfiguration einfach, damit spätere Audits und Rollbacks schnell gehen. Erst wenn Muster klar sind, gehe ich tiefer ins Pinning.
Manuelle CPU‑Affinity für maximale Kontrolle
Bei sehr hohen pps‑Raten pinne ich RX‑Queues an ausgewählte Kerne desselben NUMA‑Nodes und trenne Applikations‑Threads bewusst davon. Ich isoliere einzelne Kerne für Interrupts, lasse Worker auf benachbarten Kernen laufen und achte strikt auf Cache‑Lokalität. So reduziere ich Cross‑Node‑Zugriffe und minimiere teure Kontextwechsel im Hot Path. Für reproduzierbare Ergebnisse dokumentiere ich die IRQ‑Masken, die Queue‑Zuordnung und die Thread‑Affinity der Dienste klar. Diese Klarheit hält die Paketlaufzeiten konstant und verringert Ausreißer.
CPU‑Optimierung und Anwendungen sauber abstimmen
Ich setze den CPU‑Governor häufig auf „performance“, weil Taktwechsel die Latenzsprünge vergrößern. Kritische Prozesse wie Nginx, HAProxy oder Datenbanken binde ich an Kerne, die nahe an den IRQ‑Kernen liegen, oder ich separiere bewusst, wenn das Cache‑Profil es verlangt. Wichtig bleibt, Kontextwechsel zu begrenzen und den Kernel aktuell zu halten, damit Optimierungen im Net‑Stack greifen. Ich messe die Auswirkungen jeder Änderung, statt Annahmen zu treffen, und passe Schritt für Schritt an. So entsteht ein Setup, das unter Last berechenbar reagiert.
Monitoring und Messung richtig aufsetzen
Ohne Messwerte bleibt Tuning ein Ratespiel, darum starte ich mit sar, mpstat, vmstat, nstat, ss sowie ethtool -S. Für strukturierte Lasttests nutze ich iperf3 und schaue mir neben Durchsatz vor allem pps, Latenz, Retransmits und Kernauslastung an. Langfristige Trends zeichne ich mit gängigen Monitoring‑Systemen auf, um Muster wie Abendspitzen, Backup‑Fenster oder Kampagnen zu erkennen. Wer den Datenpfad ganzheitlich verstehen will, profitiert von einer Sicht auf die Packet‑Processing‑Pipeline vom NIC‑IRQ bis in den Userspace. Erst die Kombination dieser Signale zeigt, ob IRQ‑Balancing und Affinity die gewünschte Wirkung bringen.
NAPI, Softirqs und ksoftirqd verstehen
Um Latenzspitzen bei hoher pps‑Last zu beherrschen, berücksichtige ich die NAPI‑Mechanik und das Zusammenspiel von Hardirqs und Softirqs. Nach dem ersten Hardware‑IRQ holt NAPI im Poll‑Modus mehrere Pakete aus der RX‑Queue, um IRQ‑Stürme zu vermeiden. Werden Softirqs nicht zeitnah abgearbeitet, wandern sie in ksoftirqd/N Threads, die nur mit normaler Priorität laufen – ein klassischer Grund für steigende Tail‑Latenzen. Ich beobachte /proc/softirqs und /proc/net/softnet_stat; ein hoher „time_squeeze“‑Wert oder Drops weisen auf ein zu knappes Budget hin. Mit sysctl -w net.core.netdev_budget_usecs=8000 und sysctl -w net.core.netdev_budget=600 erhöhe ich testweise die Abarbeitungszeit pro NIC‑Poll und das Paketbudget. Wichtig: Ich steigere Werte schrittweise, messe und prüfe, ob CPU‑Jitter oder Interferenzen mit Applikationsthreads entstehen.
RSS‑Hash und Indirection‑Table feinjustieren
RSS verteilt Flows über die Indirection‑Table (RETA) auf Queues. Ich verifiziere Hash‑Schlüssel und Tabelle mit ethtool -n ethX rx-flow-hash tcp4 und stelle bei Bedarf die Verteilung symmetrisch ein. Mit ethtool -X ethX equal N oder gezielt pro Entry (ethtool -X ethX hkey ... hfunc toeplitz indir 0:1 1:3 ...) gleiche ich Zuordnungen an die bevorzugten Kerne eines NUMA‑Nodes an. Ziel ist Flow‑Stickiness: Ein Flow bleibt auf demselben Kern, damit Cache‑Lokalität und Lock‑Contention im Stack minimal bleiben. Für Umgebungen mit vielen kurzen UDP‑Flows erhöhe ich rps_flow_cnt pro RX‑Queue, damit die Software‑Verteilung genug Buckets hat und keine Hotspots erzeugt. Ich behalte im Blick, dass symmetrische Hashes bei ECMP‑Topologien helfen, aber im Serverkontext vor allem Kern‑Balance zählt.
Offloads, GRO/LRO und Ringgrößen sinnvoll wählen
Hardware‑Offloads entlasten die CPU, können aber Latenzprofile verändern. Ich prüfe mit ethtool -k ethX, ob TSO/GSO/UDP_SEG auf TX und GRO/LRO auf RX aktiv sind. GRO bündelt Pakete im Kernel und ist für Throughput fast immer nützlich; LRO kann in Routing‑ oder Filtering‑Setups problematisch sein und bleibt dort besser aus. Für Latenz‑kritische APIs teste ich kleinere GRO‑Aggregation (oder temporär aus), wenn p99‑Latenzen dominieren. Ebenso justiere ich Ringgrößen über ethtool -G ethX rx 1024 tx 1024: Größere Ringe fangen Bursts ab, erhöhen aber Latenz im Stau; zu kleine Ringe führen zu rx_missed_errors. Ich verlasse mich auf Messwerte aus ethtool -S (z. B. rx_no_buffer_count, rx_dropped) und stimme das mit BQL (Byte Queue Limits, kernel‑seitig automatisch) ab, damit TX‑Queues nicht überfüttern.
Virtualisierung: IRQs in VMs und am Hypervisor
In virtualisierten Setups kontrolliere ich die physische NIC‑Verteilung am Host und setze dort IRQ‑Balancing klar auf. VMs erhalten ausreichend vCPUs, aber ich vermeide blindes Overcommitment, damit Scheduling‑Verzögerungen die Latenz nicht aufschaukeln. Moderne paravirtualisierte Treiber wie virtio‑net oder vmxnet3 liefern mir die besseren Pfade für hohe pps‑Raten. Innerhalb der VM prüfe ich erneut Affinity und Queue‑Zahl, damit der Gast nicht zum Flaschenhals wird. Entscheidend ist die durchgängige Sicht auf Host und Gast, damit der gesamte Datenpfad stimmt.
Virtualisierung vertiefen: SR‑IOV, vhost und OVS
Für sehr hohe pps‑Raten nutze ich am Hypervisor SR‑IOV: Virtuelle Funktionen (VFs) der physischen NIC binde ich direkt an VMs und pinne sie an Kerne des passenden NUMA‑Nodes. Das umgeht Teile des Host‑Stacks und reduziert Latenz. Wo SR‑IOV nicht passt, achte ich auf vhost‑net und pinne die vhost‑Threads wie Applikations‑Worker und IRQ‑Kerne, damit keine Cross‑NUMA‑Sprünge entstehen. In Overlay‑ oder Switching‑Setups bewerte ich die Mehrkosten durch Linux‑Bridge oder OVS; für Extrem‑Profile setze ich OVS‑DPDK nur, wenn der operative Aufwand den messbaren Vorteil rechtfertigt. Auch hier gilt: Ich messe pps, Latenz und CPU‑Verteilung vor Entscheidungen, nicht danach.
Busy Polling und Userspace‑Tuning
Für latenzkritische Dienste kann Busy Polling den Jitter senken. Ich aktiviere testweise sysctl -w net.core.busy_read=50 und net.core.busy_poll=50 (Mikrosekunden) und setze per Socket‑Option SO_BUSY_POLL selektiv für betroffene Sockets. Der Userspace pollt dann kurz vor der Blockierung und erwischt Pakete, bevor sie tiefer in die Queues wandern. Das kostet CPU‑Zeit, liefert aber oft stabilere p99‑Latenzen. Ich halte die Werte klein, beobachte Kernauslastung und kombiniere Busy Polling nur mit klarer Thread‑Affinity und einem fixen CPU‑Governor, sonst heben sich Effekte gegenseitig auf.
Paketfilter, Conntrack und eBPF‑Kosten im Blick
Firewalling und NAT sind Teil des Datenpfads. Ich prüfe daher die nftables/iptables‑Regelwerke und räume tote Regeln oder tiefe Ketten auf. In stark frequentierten Setups passe ich die Conntrack‑Tabellengröße an (nf_conntrack_max, Hash‑Bucket‑Zahl) oder deaktiviere Conntrack gezielt für stateless‑Flows. Werden eBPF‑Programme (XDP, tc‑BPF) genutzt, messe ich deren Laufzeitkosten je Hook und priorisiere „early drop/redirect“, um teure Pfade zu entlasten. Wichtig ist eine eindeutige Verantwortlichkeit: Entweder greift die Optimierung im NIC‑Offload, im eBPF‑Programm oder im klassischen Stack – Doppelarbeit erhöht nur die Latenz.
CPU‑Isolation und Housekeeping‑Kerne
Für absolut deterministische Latenz lagere ich Hintergrundarbeiten auf Housekeeping‑CPUs aus. Kernel‑Parameter wie nohz_full=, rcu_nocbs= und irqaffinity= helfen, dedizierte Kerne weitgehend von Tick‑Handling, RCU‑Callbacks und fremden IRQs freizuhalten. Ich isoliere ein Set von Kernen für Applikations‑Worker und ein anderes für IRQs und Softirqs; Systemdienste und Timer laufen auf separaten Kernen. Das sorgt für saubere Cache‑Profile und reduziert Preemption‑Effekte. Hyper‑Threading kann in Einzelfällen Jitter verstärken; ich teste, ob das Deaktivieren pro Core‑Paar die p99‑Latenzen glättet, bevor ich eine globale Entscheidung treffe.
Diagnose‑Playbook und typische Anti‑Pattern
Wenn Drops oder Latenzspitzen auftauchen, gehe ich strukturiert vor: 1) /proc/interrupts auf ungleichmäße Verteilung prüfen. 2) ethtool -S auf RX/TX‑Drops, FIFO‑Errors, rx_no_buffer_count checken. 3) /proc/net/softnet_stat nach „time_squeeze“ oder „drops“. 4) mpstat -P ALL und top für ksoftirqd‑Aktivität. 5) Applikations‑Metriken (Anzahl aktiver Verbindungen, Retransmits mit ss -ti). Anti‑Pattern, die ich meide: pauschal riesige RX‑Ringe (versteckt Stau), wildes Ein‑/Ausschalten von Offloads ohne Messung, Mischen von festen Affinities mit aggressivem irqbalance, oder RPS und RSS gleichzeitig ohne klare Zielarchitektur. Jede Änderung bekommt einen Mess‑Vorher/Nachher‑Vergleich und ein kurzes Protokoll.
Beispielkonzepte für Webhosting und APIs
Klassischer Webhosting‑Server
Bei vielen kleinen Websites aktiviere ich irqbalance, stelle mehrere Queues ein und wähle den Performance‑Governor. Ich messe L7‑Latenzen während Peaks und achte auf pps‑Spitzen, die vor allem bei TLS und HTTP/2 entstehen. Reichen Hardware‑Queues nicht, ergänze ich RPS für zusätzliche Verteilung in der Software‑Ebene. Diese Justierung hält Antwortzeiten konstant, auch wenn die Gesamtauslastung moderat wirkt. Regelmäßige Checks von /proc/interrupts zeigen mir, ob einzelne Kerne kippen.
Hochlast‑Reverse‑Proxy oder API‑Gateway
Für Frontends mit hoher Verbindungszahl pinne ich RX‑Queues fein an definierte Kerne und positioniere Proxy‑Worker auf nahegelegenen Kernen. Ich entscheide bewusst, ob irqbalance aktiv bleibt oder ob fixes Pinning die klareren Ergebnisse liefert. Fehlen ausreichend Queues, wähle ich gezielt RPS/XPS und kalibriere Coalescing, um IRQ‑Stürme zu vermeiden. So erreiche ich niedrige Latenz bei sehr hoher pps‑Rate und halte Tail‑Latenzen im Griff. Dokumentation jeder Änderung erleichtert spätere Audits und hält das Verhalten vorhersagbar.
Anbieterwahl und Hardwarekriterien
Ich achte auf NICs mit Multi‑Queue, verlässliche Latenz im Backbone und aktuelle Kernel‑Stände der Plattform. Ausgewogene CPU‑Topologie und klare NUMA‑Trennung verhindern, dass Netzwerk‑Interrupts in entfernte Speicherzonen greifen. Für Projekte mit hohen pps‑Raten honoriert die Wahl der Infrastruktur jede Stunde Tuning, weil die Hardware Reserves liefert. In Praxisvergleichen habe ich mit Anbietern gut gearbeitet, die Performance‑Profile offenlegen und IRQ‑freundliche Defaults mitbringen, etwa Anbieter wie webhoster.de. Solche Setups erlauben mir, IRQ‑Balancing, RSS und Affinity wirkungsvoll zu nutzen und die Reaktionszeiten eng zu halten.
Schrittweise Vorgehensweise für eigenes Tuning
Schritt 1: Ich ermittle den Ist‑Zustand mit iperf3, sar, mpstat, nstat und ethtool -S, damit ich klare Ausgangswerte habe. Schritt 2: Läuft irqbalance nicht, aktiviere ich den Dienst, warte unter Last und vergleiche Latenz, pps und Drops. Schritt 3: Ich gleiche Queue‑Zahl und RSS‑Konfiguration an die Kerne des zugehörigen NUMA‑Nodes an. Schritt 4: Den CPU‑Governor setze ich auf „performance“ und ordne zentrale Dienste passenden Kernen zu. Schritt 5: Erst danach feile ich an manueller Affinity und NUMA‑Pinning, sofern Messwerte noch Engstellen zeigen. Schritt 6: Über Tage prüfe ich Trends, um Event‑Peaks, Backups oder Marketing‑Spitzen sicher einzuordnen.
Kurz zusammengefasst
Effektives IRQ‑Balancing verteilt Netzwerkarbeit über passende Kerne, dämpft Latenzen und verhindert Drops bei hoher pps‑Rate. In Kombination mit Multi‑Queue‑NICs, RSS/RPS, passendem CPU‑Governor und sauberer Thread‑Affinity schöpfe ich den Net‑Stack verlässlich aus. Messwerte aus ethtool -S, nstat, sar und iperf3 führen mich schrittweise zum Ziel, statt im Dunkeln zu stochern. Wer NUMA‑Topologie, IRQ‑Pinning und Applikations‑Platzierung zusammendenkt, hält Antwortzeiten niedrig – auch bei Lastspitzen. So bleibt Hochlast‑Hosting spürbar reaktionsstark, ohne unnötige CPU‑Reserven zu verbrennen.
