IRQ-Affinity und Netzwerkkarten-Interrupt-Tuning fuer Multi-Core-Server

1. Warum IRQ-Affinity auf Hochlast-Servern zaehlt

Jedes ankommende Netzwerkpaket muss die CPU ueber einen Hardware-Interrupt (IRQ) informieren, dass Daten bereitstehen. Auf einem Server mit einer einzigen Netzwerkkarte und einer einzigen Interrupt-Queue landen standardmaessig saemtliche dieser Interrupts auf genau einem CPU-Kern, unabhaengig davon, wie viele Kerne der Server insgesamt hat. Bei niedriger Paketrate ist das unproblematisch, bei einem Magento-Server mit hoher gleichzeitiger Nutzerzahl und entsprechend vielen TCP-Verbindungen kann dieser eine Kern jedoch schnell zu 100 Prozent mit Interrupt-Verarbeitung ausgelastet sein, waehrend die uebrigen Kerne fast untaetig bleiben.

Genau hier setzt IRQ-Affinity an: die gezielte Zuordnung, welcher Interrupt von welchem CPU-Kern bearbeitet wird. Moderne Netzwerkkarten bieten dafuer mehrere Hardware-Warteschlangen, sodass Interrupts von vornherein auf mehrere Kerne verteilt werden koennen, statt alle auf einem einzigen Kern zu buendeln. Ohne bewusste IRQ-Affinity-Konfiguration bleibt dieses Potenzial oft ungenutzt, weil die Standardeinstellung nicht immer optimal zur tatsaechlichen Kernanzahl und Workload-Verteilung des Servers passt.

Dieser Artikel zeigt, wie Interrupt-Verteilung analysiert wird, wie IRQ-Affinity manuell und automatisch konfiguriert werden kann, und wie Receive Side Scaling sowie Interrupt Coalescing zusammen die Netzwerklast gleichmaessig ueber alle Kerne eines Magento-Webservers verteilen.

2. Wie Interrupts und Kernel-Interrupt-Verarbeitung funktionieren

Ein Hardware-Interrupt unterbricht kurzzeitig die normale Ausfuehrung eines CPU-Kerns, damit dieser sofort auf ein Ereignis reagieren kann, etwa ein eingetroffenes Netzwerkpaket. Der Kernel verarbeitet einen Interrupt in zwei Phasen: dem sogenannten Top Half, der minimal und extrem schnell ist und nur das Nötigste erledigt, und dem Bottom Half beziehungsweise Softirq, der die eigentliche, aufwendigere Verarbeitung uebernimmt, etwa das Weiterreichen des Pakets an den Netzwerkstack.

Wenn saemtliche Netzwerkinterrupts ohne IRQ-Affinity-Konfiguration auf einem einzigen Kern landen, muss dieser Kern sowohl den Top Half als auch einen erheblichen Teil der Softirq-Verarbeitung staemmen. Bei hoher Paketrate zeigt sich das im Kernel-Metrik si (Software Interrupt) in Tools wie top, wo ein einzelner Kern einen ungewoehnlich hohen Softirq-Anteil aufweist, waehrend andere Kerne kaum davon betroffen sind. Diese Schieflage ist ein direktes Symptom fehlender oder falsch konfigurierter IRQ-Affinity.

3. Interrupt-Verteilung mit /proc/interrupts analysieren

Die Datei /proc/interrupts zeigt fuer jeden Interrupt, wie viele Ereignisse pro CPU-Kern bereits verarbeitet wurden. Fuer eine Netzwerkkarte mit mehreren Warteschlangen erscheint typischerweise pro Warteschlange eine eigene Zeile, benannt nach dem Interface und der Queue-Nummer. Steigen die Werte in nur einer oder zwei Spalten kontinuierlich stark an, waehrend die uebrigen Spalten praktisch stillstehen, ist das ein klares Indiz fuer unguenstige IRQ-Affinity.

Ein wiederholter Blick im Abstand von wenigen Sekunden, kombiniert mit einer Differenzbildung der Zaehlerwerte, zeigt die tatsaechliche Verteilung waehrend eines konkreten Lastfensters deutlich praeziser als eine einmalige Momentaufnahme. Fuer Server mit mehreren Netzwerkkarten oder Bonding-Interfaces sollte diese Analyse getrennt fuer jede physische Karte erfolgen, weil sich Ungleichgewichte pro Karte unterschiedlich stark auswirken koennen.

# Show interrupt counters per CPU core for a specific interface
grep eth0 /proc/interrupts

# Take two snapshots 5 seconds apart to see live distribution
cat /proc/interrupts > /tmp/irq_before
sleep 5
cat /proc/interrupts > /tmp/irq_after
diff /tmp/irq_before /tmp/irq_after | grep eth0

# List all IRQ numbers assigned to a given network interface
cat /sys/class/net/eth0/device/msi_irqs 2>/dev/null

4. irqbalance verstehen und wann es abgeschaltet werden sollte

Auf den meisten Linux-Distributionen laeuft standardmaessig der Dienst irqbalance, der versucht, Interrupts automatisch und dynamisch ueber verfuegbare CPU-Kerne zu verteilen. Fuer allgemeine Server-Workloads mit wechselnder Last ist das ein sinnvoller Kompromiss ohne manuelle Konfiguration. Fuer dedizierte Hochlast-Webserver mit vorhersehbarem Traffic-Muster kann irqbalance aber selbst zum Problem werden, weil die automatische Umverteilung periodisch CPU-Cache-Warmth zerstoert und dadurch kurzzeitig mehr Latenz verursacht, als eine statische, sorgfaeltig geplante IRQ-Affinity-Konfiguration verursachen wuerde.

Fuer Server, auf denen bestimmte CPU-Kerne bewusst fuer Netzwerkinterrupts reserviert werden sollen, waehrend andere Kerne ausschliesslich fuer PHP-FPM-Worker oder MySQL zur Verfuegung stehen, ist es deshalb ueblich, irqbalance zu deaktivieren und die IRQ-Affinity stattdessen statisch und explizit ueber smp_affinity zu setzen. Diese Entscheidung sollte aber erst nach einer Analyse der tatsaechlichen Interrupt-Verteilung getroffen werden, nicht pauschal fuer jeden Server.

# Check whether irqbalance is currently running
systemctl status irqbalance --no-pager

# Disable irqbalance for static, manual IRQ affinity control
systemctl stop irqbalance
systemctl disable irqbalance

5. IRQ-Affinity manuell mit smp_affinity setzen

Jeder Interrupt besitzt unter /proc/irq/<nummer>/smp_affinity eine Bitmaske, die festlegt, welche CPU-Kerne diesen Interrupt bearbeiten duerfen. Ueber diese Datei laesst sich IRQ-Affinity praezise und manuell konfigurieren, etwa um Netzwerkinterrupts bewusst auf die ersten vier Kerne eines Achtkern-Servers zu beschraenken, waehrend die restlichen vier Kerne ausschliesslich Anwendungs-Workloads verarbeiten.

Eine haeufig genutzte Strategie ist, jede Interrupt-Queue einer Netzwerkkarte auf genau einen dedizierten Kern zu binden, statt mehrere Kerne pro Queue zuzulassen. Das verhindert, dass ein einzelnes Paket zwischen Kernen migriert und dabei CPU-Cache-Lokalitaet verliert, ein Effekt der besonders bei sehr hoher Paketrate messbar zur Latenz beitraegt.

#!/usr/bin/env bash
# bind-irqs.sh — pin each NIC queue's IRQ to one dedicated CPU core
set -euo pipefail

IFACE="eth0"
CORES=(0 1 2 3)

irqs=($(grep "$IFACE" /proc/interrupts | awk -F: '{print $1}'))

for i in "${!irqs[@]}"; do
  irq="${irqs[$i]}"
  core="${CORES[$((i % ${#CORES[@]}))]}"
  mask=$(printf "%x" $((1 << core)))
  echo "$mask" > "/proc/irq/${irq}/smp_affinity"
  echo "IRQ $irq -> core $core (mask $mask)"
done

6. RSS: Receive Side Scaling fuer Mehrkern-Verteilung

Receive Side Scaling (RSS) ist eine Hardware-Funktion moderner Netzwerkkarten, die eingehende Pakete anhand eines Hash-Werts aus Quell- und Ziel-IP sowie Port bereits auf der Karte selbst auf mehrere Hardware-Warteschlangen verteilt, bevor ueberhaupt ein Interrupt ausgeloest wird. In Kombination mit passender IRQ-Affinity pro Warteschlange entsteht so eine durchgehende Parallelisierung von der Netzwerkkarte bis zum verarbeitenden CPU-Kern, ohne dass Pakete einer einzelnen TCP-Verbindung auf unterschiedlichen Kernen landen und dadurch Paket-Reihenfolge oder Cache-Lokalitaet gefaehrden.

Die Anzahl der von einer Karte unterstuetzten RSS-Warteschlangen laesst sich mit ethtool -l abfragen und, sofern die Hardware es zulaesst, mit ethtool -L auf die tatsaechliche Kernanzahl des Servers anpassen. Fuer Server mit deutlich mehr Kernen als von der Karte unterstuetzte Warteschlangen bleibt zwangslaeufig ein Teil der Kerne von der direkten Netzwerkverarbeitung ausgeschlossen, was bei der Planung von IRQ-Affinity beruecksichtigt werden sollte.

# Show current and maximum RSS queue counts
ethtool -l eth0
# Channel parameters for eth0:
# Pre-set maximums:
# Combined: 8
# Current hardware settings:
# Combined: 4

# Increase to match the server's core count (if hardware supports it)
ethtool -L eth0 combined 8

7. Interrupt Coalescing mit ethtool feinjustieren

Ohne jede Optimierung wuerde jedes einzelne Netzwerkpaket einen eigenen Interrupt ausloesen, was bei sehr hoher Paketrate zu einem Interrupt-Sturm fuehrt, der die CPU mehr mit Interrupt-Handling als mit tatsaechlicher Anwendungsarbeit beschaeftigt. Interrupt Coalescing buendelt mehrere Pakete zu einem einzigen Interrupt, entweder nach einer festen Zeitspanne oder nach einer festen Paketanzahl, was die Interrupt-Rate drastisch senkt, allerdings auf Kosten geringfuegig hoeherer Latenz pro Paket.

Die Werte lassen sich mit ethtool -c auslesen und mit ethtool -C anpassen. Fuer latenzkritische Anwendungen wird ein niedrigerer Coalescing-Wert bevorzugt, fuer durchsatzorientierte Batch-Workloads ein hoeherer Wert. Auf einem Magento-Webserver, der viele kurze HTTP-Anfragen verarbeitet, ist meist ein moderater Mittelweg sinnvoll, der weder unnoetig viele Interrupts erzeugt noch spuerbare zusaetzliche Latenz pro Anfrage einfuehrt.

# Show current interrupt coalescing settings
ethtool -c eth0

# Lower coalescing values reduce added latency per packet,
# at the cost of a higher interrupt rate under heavy load
ethtool -C eth0 rx-usecs 20 rx-frames 8

8. Typische Fehler beim IRQ-Tuning

Der haeufigste Fehler ist, IRQ-Affinity manuell zu konfigurieren, ohne vorher irqbalance zu deaktivieren. Beide Mechanismen konkurrieren dann miteinander, und irqbalance ueberschreibt die manuell gesetzten smp_affinity-Werte periodisch wieder, ohne dass eine offensichtliche Fehlermeldung auf dieses Problem hinweist. Ein zweiter haeufiger Fehler ist, Netzwerkinterrupts auf denselben Kernen zu binden, auf denen auch die rechenintensivsten PHP-FPM-Worker laufen, wodurch beide Workloads um dieselben Kerne konkurrieren, statt sich gegenseitig zu entlasten.

Ein dritter Fehler betrifft NUMA-Systeme: Werden Netzwerkinterrupts auf Kernen eines anderen NUMA-Nodes gebunden, als an dem die Netzwerkkarte physisch angeschlossen ist, entstehen zusaetzliche, vermeidbare entfernte Speicherzugriffe fuer jedes einzelne Paket. Die physische Zuordnung der Netzwerkkarte zu einem Node laesst sich mit cat /sys/class/net/eth0/device/numa_node ermitteln und sollte bei der IRQ-Planung immer beruecksichtigt werden.

9. IRQ-Strategien im Vergleich

Die folgende Tabelle stellt die wichtigsten Ansaetze fuer IRQ-Affinity auf Multi-Core-Servern gegenueber.

Fuer die meisten Magento-Webserver mit moderater bis hoher Paketrate ist statisches smp_affinity in Kombination mit ausreichend RSS-Warteschlangen der beste Kompromiss zwischen Kontrolle und Wartungsaufwand. Nur bei sehr hoher, dauerhaft konstanter Paketrate lohnt sich die dedizierte Reservierung ganzer Kerne ausschliesslich fuer Netzwerkinterrupts.

10. Zusammenfassung

IRQ-Affinity entscheidet darueber, ob Netzwerkinterrupts gleichmaessig ueber alle CPU-Kerne eines Servers verteilt werden oder sich auf einem einzigen Kern buendeln, der dann lange vor der restlichen CPU zum Flaschenhals wird. Mit /proc/interrupts laesst sich die tatsaechliche Verteilung analysieren, mit irqbalance eine dynamische Standardloesung nutzen, und mit smp_affinity eine praezise, statische Konfiguration fuer dedizierte Hochlast-Server umsetzen.

Receive Side Scaling verteilt Pakete bereits auf Hardware-Ebene ueber mehrere Warteschlangen, waehrend Interrupt Coalescing die Interrupt-Rate insgesamt senkt. Beide Mechanismen ergaenzen eine durchdachte IRQ-Affinity-Konfiguration, muessen aber immer im Zusammenspiel mit der NUMA-Topologie des Servers geplant werden, um zusaetzliche entfernte Speicherzugriffe zu vermeiden.

11. FAQ: IRQ-Affinity und Netzwerkkarten-Interrupt-Tuning