{"id":21523,"date":"2026-09-18T15:03:40","date_gmt":"2026-09-18T13:03:40","guid":{"rendered":"https:\/\/webhosting.de\/linux-irq-affinity-cpu-mehrprozessor-network-tuning-optimierung-core\/"},"modified":"2026-09-18T15:03:40","modified_gmt":"2026-09-18T13:03:40","slug":"linux-irq-afinidade-cpu-multiprocessador-rede-ajuste-otimizacao-nucleo","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/linux-irq-affinity-cpu-mehrprozessor-network-tuning-optimierung-core\/","title":{"rendered":"Afinidade de IRQ no Linux em sistemas multiprocessadores: guia pr\u00e1tico para um ajuste ideal da rede"},"content":{"rendered":"<p>Ich zeige praxisnah, wie irq affinity auf Mehrprozessorsystemen Netzwerk\u2011Interrupts gezielt an CPU\u2011Cores bindet, Latenz dr\u00fcckt und Durchsatz hebt. Mit klaren Schritten, Beispielen und einer Tabelle lege ich fest, wie ich Hex\u2011Masken w\u00e4hle, NUMA beachte und Prozesse passend pinne.<\/p>\n\n<h2>Zentrale Punkte<\/h2>\n\n<ul>\n  <li><strong>IRQ Affinity<\/strong> lenkt Hardware\u2011Interrupts gezielt auf CPUs und senkt Overhead.<\/li>\n  <li><strong>CPU Affinity<\/strong> f\u00fcr Dienste an dieselben Cores pinnen h\u00e4lt Caches lokal.<\/li>\n  <li><strong>NUMA<\/strong> beachten, Adapter und Cores derselben Node nutzen.<\/li>\n  <li><strong>irqbalance<\/strong> abw\u00e4gen: automatisch verteilen oder manuell feinsteuern.<\/li>\n  <li><strong>Monitoring<\/strong> und iterative Anpassung sichern stabile Latenzen.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/serverraum-netzwerk-tuning-8391.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>IRQ Affinity verstehen: Grundlagen und Wirkung<\/h2>\n\n<p>Auf Linux\u2011Hosts l\u00f6sen eingehende Pakete, Disk\u2011I\/O und Timer <strong>IRQs<\/strong> aus, die der Kernel an CPU\u2011Cores verteilt. Ich bestimme \u00fcber die Dateien <code>\/proc\/irq\/&lt;IRQ&gt;\/smp_affinity<\/code> und <code>...\/smp_affinity_list<\/code>, welche CPUs eine Quelle bedienen d\u00fcrfen. Eine breite Standardmaske wirkt zun\u00e4chst flexibel, doch sie erzeugt bei Last Cache\u2011Misses, teure Kontextwechsel und zerstreute SoftIRQs \u00fcber viele <strong>CPUs<\/strong>. Ich binde kritische Queues einzelner NICs an definierte Cores, entlaste Hotspots und halte Datenwege kurz. Diese Lenkung verbessert die Stabilit\u00e4t sp\u00fcrbar, sobald viele Flows gleichzeitig aktiv sind.<\/p>\n\n<h2>IRQ\u2011 und CPU\u2011Affinity abstimmen: Daten lokal halten<\/h2>\n\n<p>Ich koppelte erfolgreich die <strong>IRQ<\/strong>-Zust\u00e4ndigkeit der NIC\u2011Queues mit der CPU\u2011Zugeh\u00f6rigkeit relevanter Worker. Dazu pinne ich Webserver\u2011 oder Proxy\u2011Threads mittels <code>taskset<\/code> oder <code>CPUAffinity=<\/code> in systemd auf jene Cores, die auch die RX\/TX\u2011Interrupts verarbeiten. Dadurch bleiben Cache\u2011Lines lokal und ich reduziere Inter\u2011CPU\u2011Kommunikation auf ein Minimum, was die <strong>Latenz<\/strong> gl\u00e4ttet. Gerade API\u2011Backends, Echtzeit\u2011Dienste und virtualisierte Stacks profitieren von dieser Koh\u00e4renz. Ich teste die Bindung unter Produktionslast, bis Flows, SoftIRQs und User\u2011Space sauber aufeinanderpassen.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/netzwerktuningkonferenz9472.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Automatik gegen Feintuning: irqbalance richtig einordnen<\/h2>\n\n<p>Der Dienst <strong>irqbalance<\/strong> verteilt Interrupts automatisch \u00fcber verf\u00fcgbare Cores, was auf Allzweck\u2011Servern gut funktioniert. In hoch belasteten Netzwerk\u2011Setups bremst die Streuung jedoch Cache\u2011Lokalit\u00e4t und erschwert gezieltes Pinning. Ich schr\u00e4nke irqbalance ein oder deaktiviere ihn selektiv, wenn bestimmte Queues feste Cores ben\u00f6tigen. F\u00fcr das Grundverst\u00e4ndnis und passende Profile hilft mir dieser Leitfaden zu <a href=\"https:\/\/webhosting.de\/irq-balance-linux-konfigurieren-server\/\">irqbalance konfigurieren<\/a>. Im Ergebnis steuert die Automatik Unkritisches, w\u00e4hrend ich sensible IRQs manuell zuweise.<\/p>\n\n<h2>Schritt: Relevante IRQs sichtbar machen<\/h2>\n\n<p>Ich beginne mit einem Blick in <code>\/proc\/interrupts<\/code> und filtere nach dem Ger\u00e4tenamen wie <strong>ens192<\/strong>, <strong>eno1<\/strong> oder <strong>eth0<\/strong>. Moderne Adapter legen mehrere RX\u2011 und TX\u2011Queues an, daher finde ich eine Gruppe von IRQ\u2011Nummern, die derselben NIC zugeordnet sind. Ich achte auf Z\u00e4hlerst\u00e4nde, um Hotspots schnell zu erkennen und stark beanspruchte Queues zuerst zu binden. Diese Sicht pr\u00fcfe ich regelm\u00e4\u00dfig w\u00e4hrend Lasttests, damit die Zuordnung dauerhaft tr\u00e4gt. Zus\u00e4tzlich kontrolliere ich Treiberbezeichnungen, weil sie Hinweise auf RSS\u2011F\u00e4higkeiten und Offloading liefern.<\/p>\n\n<pre><code># Alle Interrupts einsehen\ncat \/proc\/interrupts\n\n# Nur NIC-relevante Zeilen anzeigen (Beispiel ens192)\ngrep -i ens192 \/proc\/interrupts\n<\/code><\/pre>\n\n<h2>NUMA\u2011Topologie klug nutzen<\/h2>\n\n<p>Auf Hosts mit mehreren Nodes verlagere ich IRQs vorzugsweise auf Cores jener <strong>NUMA<\/strong>-Node, an der die NIC physisch h\u00e4ngt. Ich pr\u00fcfe das mit <code>lscpu<\/code> sowie <code>numactl --hardware<\/code> und markiere passende CPU\u2011S\u00e4tze f\u00fcr die sp\u00e4tere Maskenbildung. Prozesse, die diese Netzpfade bedienen, binde ich ebenfalls an dieselbe Node und sorge \u00fcber Memory\u2011Policies f\u00fcr lokale <strong>Speicher<\/strong>-Zuweisungen. So vermeide ich teure Remote\u2011Zugriffe quer \u00fcber die QPI\/UPI\u2011Links. Diese Disziplin bringt in Latenztests rasch messbare Vorteile.<\/p>\n\n<h2>Bitmasken sicher w\u00e4hlen: Hex\u2011Logik auf einen Blick<\/h2>\n\n<p>Die Datei <code>smp_affinity<\/code> akzeptiert Hex\u2011Bitmasken, die direkt auf Core\u2011IDs abbilden und auch gro\u00dfe Systeme abdecken. Ich starte oft mit einfachen Mustern: CPU0 ist 0x1, CPU1 ist 0x2, CPU2 ist 0x4, CPU3 ist 0x8 usw., w\u00e4hrend 0xF die Cores 0\u20133 umfasst. Auf Maschinen mit vielen Cores schreibe ich mehrere 32\u2011Bit\u2011Bl\u00f6cke, getrennt durch Kommas, damit die <strong>Maske<\/strong> alle IDs sauber abbildet. Diese \u00dcbersicht hilft mir, fehlerfreie Zuweisungen vorzunehmen und unbeabsichtigte Verlagerungen zu vermeiden. Die folgende Tabelle nutze ich h\u00e4ufig als Ged\u00e4chtnisst\u00fctze.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>CPU\u2011Nummer<\/th>\n      <th>Bit (bin\u00e4r)<\/th>\n      <th>Hex\u2011Maske<\/th>\n      <th>Hinweis<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>0<\/td>\n      <td>&#8230;0001<\/td>\n      <td>0x1<\/td>\n      <td><strong>CPU0<\/strong> oft entlasten und nur sparsam nutzen.<\/td>\n    <\/tr>\n    <tr>\n      <td>1<\/td>\n      <td>&#8230;0010<\/td>\n      <td>0x2<\/td>\n      <td>IRQ auf <strong>CPU1<\/strong> pinnen.<\/td>\n    <\/tr>\n    <tr>\n      <td>2<\/td>\n      <td>&#8230;0100<\/td>\n      <td>0x4<\/td>\n      <td>IRQ auf CPU2 pinnen.<\/td>\n    <\/tr>\n    <tr>\n      <td>3<\/td>\n      <td>&#8230;1000<\/td>\n      <td>0x8<\/td>\n      <td>IRQ auf CPU3 pinnen.<\/td>\n    <\/tr>\n    <tr>\n      <td>0\u20133<\/td>\n      <td>&#8230;1111<\/td>\n      <td>0xF<\/td>\n      <td>Alle vier Cores zulassen, Latenz steigt oft leicht.<\/td>\n    <\/tr>\n    <tr>\n      <td>0\u20137<\/td>\n      <td>11111111<\/td>\n      <td>0xFF<\/td>\n      <td>Breite Verteilung, Cache\u2011Lokalit\u00e4t leidet.<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux-irq-affinity-network-8347.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>IRQ\u2011Affinity setzen: so binde ich Queues an Cores<\/h2>\n\n<p>Nachdem ich die Queue\u2011IRQs der NIC identifiziert habe, verteile ich sie auf dedizierte <strong>Cores<\/strong> wie 1, 2 und 3, um parallele Verarbeitung sauber zu skalieren. Damit bleibt jede RX\/TX\u2011Queue bei ihrem Core, was Cross\u2011Talk vermeidet und SoftIRQ\u2011Arbeit konsistent h\u00e4lt. W\u00e4hrend des Feinschliffs vergleiche ich Durchsatz und Latenz, bis die Verteilung zuverl\u00e4ssig tr\u00e4gt. F\u00fcr einen tieferen Einstieg hilft mir ein kurzer <a href=\"https:\/\/webhosting.de\/server-irq-affinity-multicore-netzwerkoptimierung-performance\/\">Praxisleitfaden<\/a> mit Varianten je nach Adapter. Die Kommandos setze ich bewusst in Wartungsfenstern und sichere sie per Boot\u2011Skript ab.<\/p>\n\n<pre><code># Beispiel: drei Queue-IRQs an CPU1..3 binden\necho 2 &gt; \/proc\/irq\/181\/smp_affinity   # CPU1 (0x2)\necho 4 &gt; \/proc\/irq\/182\/smp_affinity   # CPU2 (0x4)\necho 8 &gt; \/proc\/irq\/183\/smp_affinity   # CPU3 (0x8)\n<\/code><\/pre>\n\n<h2>Prozess\u2011Pinning: Dienste auf dieselben Cores legen<\/h2>\n\n<p>Ich pinne Anwendungs\u2011Worker auf jene <strong>CPUs<\/strong>, die die zugeh\u00f6rigen IRQs verarbeiten, damit Datenpfade kurz bleiben. Unter systemd nutze ich <code>CPUAffinity=1 2 3<\/code> oder starte einmalig mit <code>taskset -c 1-3<\/code>. F\u00fcr Multi\u2011Worker\u2011Server vergebe ich feste Core\u2011S\u00e4tze pro Worker\u2011Gruppe, damit keine Konkurrenz entsteht. Diese Kopplung bringt konstant niedrigere <strong>Latenzen<\/strong>, weil CPU\u2011Caches treffend gef\u00fcllt bleiben. Nach \u00c4nderungen kontrolliere ich Threads, Sockets und SoftIRQs mit htop, ss und perf.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/tech_office_night_9274.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Network Tuning: RSS, RPS\/RFS und Kernel\u2011Parameter verbinden<\/h2>\n\n<p>Viele NICs verteilen Pakete per <strong>RSS<\/strong> \u00fcber Queues, die ich anschlie\u00dfend mit IRQ\u2011Affinity an Cores binde. Details und Wirkprinzipien fasse ich unter <a href=\"https:\/\/webhosting.de\/receive-side-scaling-rss-10g-25g-linux-server-optimierung-bitrate\/\">Receive Side Scaling<\/a> kompakt zusammen. Zus\u00e4tzlich steuere ich RPS\/RFS so, dass SoftIRQs nicht gegen die harte Pinning\u2011Logik arbeiten. Parallel passe ich Puffer \u00fcber <code>net.core.rmem_max<\/code> und <code>net.core.wmem_max<\/code> an und pr\u00fcfe TCP\u2011Optionen wie <code>tcp_timestamps<\/code>. Diese Bausteine zahlen auf dieselbe Zielgr\u00f6\u00dfe ein: geringe Latenz bei hoher <strong>Bitrate<\/strong>.<\/p>\n\n<h2>MSI\u2011X und Queue\u2011Layout richtig deuten<\/h2>\n\n<p>Moderne NICs nutzen MSI\u2011X und legen f\u00fcr jede RX\/TX\u2011Queue eigene IRQs an. Ich pr\u00fcfe zuerst, wie viele Queues und Kan\u00e4le der Treiber aktuell aktiviert hat, und passe das dem Core\u2011Budget der passenden NUMA\u2011Node an. So verhindere ich, dass zu viele Queues auf zu wenige Cores dr\u00e4ngen oder umgekehrt Kapazit\u00e4t brachliegt.<\/p>\n\n<pre><code># Queue- und Kanalanzahl pr\u00fcfen und anpassen\nethtool -l ens192           # aktuelle Limits (RX\/TX\/combined)\nethtool -L ens192 combined 4  # z.B. 4 Queues aktivieren\n\n# RSS-Indirection und Hash-Einstellung sichten\nethtool -x ens192           # Indirection-Table und Hash-Key anzeigen\n<\/code><\/pre>\n\n<p>Viele Treiber benennen IRQs sprechend (z.B. <em>ens192-TxRx-0<\/em>). Ich halte die Indirection\u2011Table konsistent zur Core\u2011Zuweisung, damit Flows stabil auf \u201eihre\u201c Queue fallen. Weicht die Hardware\u2011Verteilung ab, entstehen unn\u00f6tige Wanderungen der SoftIRQs.<\/p>\n\n<h2>RPS\/RFS und XPS stimmig einsetzen<\/h2>\n\n<p>RPS\/RFS kann Pakete softwareseitig \u00fcber Cores verteilen \u2013 gut f\u00fcr NICs ohne viele Queues, aber kontraproduktiv, wenn ich bereits per RSS und IRQ\u2011Affinity exakt binde. Ich entscheide daher bewusst: Entweder harte Bindung \u00fcber RSS+IRQ\u2011Affinity und <strong>RPS aus<\/strong>, oder wenige Hardware\u2011Queues und <strong>RPS gezielt an<\/strong>. Zus\u00e4tzlich richte ich XPS f\u00fcr die TX\u2011Richtung ein, damit ausgehende Pakete von den \u201erichtigen\u201c Cores abgeschickt werden.<\/p>\n\n<pre><code>IF=ens192\n\n# RPS komplett deaktivieren (bei sauberem IRQ-Pinning via RSS)\nfor q in \/sys\/class\/net\/$IF\/queues\/rx-*\/rps_cpus; do echo 0 &gt; \"$q\"; done\necho 0 &gt; \/proc\/sys\/net\/core\/rps_sock_flow_entries\n\n# Alternativ: RPS gezielt aktivieren (Beispiel: CPUs 1-3)\nfor q in \/sys\/class\/net\/$IF\/queues\/rx-*\/rps_cpus; do echo 0-0,0-0,0-0,0-0 &gt; \/dev\/null; done\n# Besser: smp_affinity_list-\u00e4hnliche Syntax nutzen:\nfor q in \/sys\/class\/net\/$IF\/queues\/rx-*\/rps_cpus; do echo 1-3 &gt; \"$q\"; done\necho 32768 &gt; \/proc\/sys\/net\/core\/rps_sock_flow_entries\necho 32768 &gt; \/proc\/sys\/net\/ipv4\/tcp_rfs_sock_flow_entries\n\n# XPS passend zu den ausgew\u00e4hlten Worker-CPUs setzen (TX-Pfade)\nfor q in \/sys\/class\/net\/$IF\/queues\/tx-*; do echo 1-3 &gt; \"$q\"\/xps_cpus; done\n<\/code><\/pre>\n\n<p>Wichtig ist die Koh\u00e4renz: RX\u2011IRQ\u2011Core, ksoftirqd\u2011Last und Worker\u2011Thread sollten auf demselben Core (oder Core\u2011Paar) liegen. Damit verschwinden viele Cross\u2011Core\u2011Bounce\u2011Effekte.<\/p>\n\n<h2>SMT\/Hyper\u2011Threading und Core\u2011Paare ber\u00fccksichtigen<\/h2>\n\n<p>Auf Systemen mit SMT ergibt es oft Sinn, einen physischen Core f\u00fcr einen RX\u2011IRQ zu reservieren und den zugeh\u00f6rigen Worker auf den <em>Sibling\u2011Thread<\/em> zu legen \u2013 oder bewusst zu trennen, wenn der Workload rechenlastig ist. Ich ermittele die Thread\u2011Paare aus der Topologie und treffe dann eine klare Entscheidung statt zuf\u00e4lliger Verteilung.<\/p>\n\n<pre><code># Sibling-Paare ermitteln\nfor c in \/sys\/devices\/system\/cpu\/cpu*\/topology\/thread_siblings_list; do\n  echo \"$(basename \"$(dirname \"$c\")\") : $(cat \"$c\")\"\ndone\n<\/code><\/pre>\n\n<p>Teile ich mir RX\u2011IRQ und User\u2011Space\u2011Worker auf demselben physischen Core (verschiedene SMT\u2011Threads), entsteht gute L1\/L2\u2011Lokalit\u00e4t, aber bei CPU\u2011Bound\u2011Workloads kann es Engp\u00e4sse geben. Alternativ verteile ich IRQ auf Core X und Worker auf Core Y derselben NUMA\u2011Node, um echte Parallelit\u00e4t zu erhalten. Beide Varianten teste ich A\/B und w\u00e4hle, was die stabilere Latenz liefert.<\/p>\n\n<h2>smp_affinity_list, effective_affinity und Defaults nutzen<\/h2>\n\n<p>Neben Hex\u2011Masken schreibe ich gern in <code>smp_affinity_list<\/code>, da sich damit Bereiche wie <code>1-3,6,8-9<\/code> komfortabel setzen lassen. Zur Kontrolle pr\u00fcfe ich <code>effective_affinity<\/code> bzw. <code>effective_affinity_list<\/code>, weil Kernel oder Treiber gewisse CPUs ausklammern k\u00f6nnen (z.B. offlined Cores oder \u201emanaged interrupts\u201c).<\/p>\n\n<pre><code># Menschlich lesbare Zuweisung\necho 1-3 &gt; \/proc\/irq\/181\/smp_affinity_list\n\n# Effektive Bindung verifizieren\ncat \/proc\/irq\/181\/effective_affinity_list\n<\/code><\/pre>\n\n<p>Damit neue oder nach einem Treiber\u2011Reload hinzugekommene IRQs nicht wieder breit gestreut werden, setze ich bei Bedarf <code>\/proc\/irq\/default_smp_affinity<\/code> auf einen sinnvollen Grundwert (z.B. alle Cores der relevanten NUMA\u2011Node, jedoch ohne CPU0). Einzelne kritische IRQs \u00fcbersteuere ich anschlie\u00dfend gezielt.<\/p>\n\n<h2>Persistenz \u00fcber Reboots und Reloads herstellen<\/h2>\n\n<p>Affinity\u2011Einstellungen sind fl\u00fcchtig. Ich sichere sie per systemd\u2011Oneshot\u2011Unit, die nach dem Netzwerkinitialisierungs\u2011Ziel l\u00e4uft, oder \u00fcber ein kleines Skript, das IRQ\u2011Listen dynamisch ermittelt und abbildet. So bleiben Zuweisungen auch nach Kernel\u2011Updates und Link\u2011Resets erhalten.<\/p>\n\n<pre><code># \/usr\/local\/sbin\/net-irq-pin.sh (Beispiel)\n#!\/bin\/bash\nset -euo pipefail\nIF=${1:-ens192}\nCPUS=\"1-3\"   # Ziel-CPUs (NUMA-konsistent w\u00e4hlen)\nfor irq in $(grep -i \"$IF\" \/proc\/interrupts | awk '{print $1}' | tr -d ':'); do\n  echo \"$CPUS\" &gt; \/proc\/irq\/$irq\/smp_affinity_list || true\ndone\n\n# systemd-Unit (skizziert)\n# \/etc\/systemd\/system\/net-irq-pin.service\n[Unit]\nDescription=Pin NIC IRQs\nAfter=network-online.target\n\n[Service]\nType=oneshot\nExecStart=\/usr\/local\/sbin\/net-irq-pin.sh ens192\n\n[Install]\nWantedBy=multi-user.target\n<\/code><\/pre>\n\n<p>Wichtig: Ich rufe das Skript erneut auf, wenn der Treiber neu geladen oder die Queue\u2011Anzahl ge\u00e4ndert wurde, da sich IRQ\u2011Nummern dann verschieben.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/Linux_IRQ_Affinity_3692.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Virtualisierung und Container: Host und Gast zusammen denken<\/h2>\n\n<p>In KVM\u2011Umgebungen binde ich auf dem <strong>Host<\/strong> die physischen NIC\u2011IRQs an Cores der passenden NUMA\u2011Node. Parallel pinne ich <em>vhost\u2011net<\/em>\u2011Threads und den QEMU\u2011Prozess (oder einzelne vCPUs) ebenfalls dort, damit die Datenpfade host\u2011seitig kurz bleiben. Im <strong>Gast<\/strong> richte ich die IRQ\u2011Affinity der vNICs an jene vCPUs, die ich host\u2011seitig mit physischen Cores verheiratet habe. Container\u2011Workloads (cgroups\/cpuset) profitieren, wenn die erlaubten CPUs der Container mit den RX\/TX\u2011Cores des Hosts \u00fcberlappen \u2013 sonst entstehen vermeidbare Fernzugriffe.<\/p>\n\n<h2>Analyse vertiefen: SoftIRQs, NAPI und Stau erkennen<\/h2>\n\n<p>Neben <code>\/proc\/interrupts<\/code> schaue ich in <code>\/proc\/softirqs<\/code>, um zu sehen, ob viel Arbeit im Kontext von <em>ksoftirqd<\/em> statt direkt im IRQ\u2011Handler erledigt wird \u2013 ein Hinweis auf anhaltend hohe Last. Mit <code>napi_defer_hard_irqs<\/code> (Kernel\u2011abh\u00e4ngig) und sauberen Queue\u2011Zuweisungen reguliere ich, wie aggressiv NAPI batcht. <code>ethtool -S &lt;IF&gt;<\/code> gibt mir pro Queue Statistiken f\u00fcr Drops, Busy\u2011Zust\u00e4nde und Packetrates; hier erkenne ich unbalancierte Queues und justiere Affinity oder RSS\u2011Indirection entsprechend.<\/p>\n\n<pre><code># Schnell\u00fcberblick \u00fcber SoftIRQ-Verteilung\ncat \/proc\/softirqs | egrep 'NET_RX|NET_TX'\n\n# Treiber-\/Queue-Statistiken einsehen\nethtool -S ens192 | egrep -i 'rx|tx|drop|busy'\n<\/code><\/pre>\n\n<h2>Praxis: Mapping f\u00fcr 4 Queues auf einer Node<\/h2>\n\n<p>Ein typisches Setup, das ich h\u00e4ufig einsetze: NIC auf NUMA\u2011Node0 mit 4 RSS\u2011Queues. Ich vermeide CPU0 und binde die Queues an CPU1\u20114. Die zugeh\u00f6rigen Web\u2011 oder Proxy\u2011Worker lege ich ebenfalls auf 1\u20114, XPS weise ich identisch zu, RPS bleibt aus. Damit erhalte ich kurze, konsistente Pfade in beide Richtungen.<\/p>\n\n<pre><code>IF=ens192\nQUEUES=(181 182 183 184)   # Beispiel-IRQs (vorher ermitteln)\nCPUS=\"1-4\"\n\n# IRQ-Affinity und XPS setzen\nfor i in ${!QUEUES[@]}; do\n  echo \"$CPUS\" &gt; \/proc\/irq\/${QUEUES[$i]}\/smp_affinity_list\ndone\nfor q in \/sys\/class\/net\/$IF\/queues\/tx-*; do echo \"$CPUS\" &gt; \"$q\"\/xps_cpus; done\n\n# Worker pinnen (systemd oder taskset)\n# systemd: CPUAffinity=1 2 3 4\n# Einmalig: taskset -c 1-4 &lt;dienst&gt;\n<\/code><\/pre>\n\n<p>Skaliert die Last weiter, erh\u00f6he ich die Queue\u2011Anzahl (<code>ethtool -L<\/code>) bis zur Zahl sinnvoller Cores der Node und verteile starr nach einem wiedererkennbaren Muster (z.B. Queue\u2011ID \u2192 Core\u2011ID), damit Flows im Zeitverlauf nicht \u201ewandern\u201c.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/serverraum-tuning-4632.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Best Practices f\u00fcr Multi\u2011Core\u2011Hosts<\/h2>\n\n<p>Ich entlaste <strong>CPU0<\/strong>, da dort h\u00e4ufig Timer und Kernel\u2011Hausdienste laufen, die unter Last st\u00f6ren. Kritische IRQs setze ich daher bevorzugt auf andere Cores und lasse CPU0 nur wenige, unkritische Quellen tragen. Auf NUMA\u2011Systemen bleibe ich konsequent und halte Adapter, IRQs, Prozesse und Speicherzugriffe auf derselben <strong>Node<\/strong>. In stark beanspruchten Umgebungen trenne ich I\/O\u2011Cores von Applikations\u2011Cores und isoliere sie bei Bedarf. Alle \u00c4nderungen begleite ich mit fortlaufender Messung und passe die Zuweisungen iterativ an.<\/p>\n\n<h2>Messbar vorgehen: Analyse, Skripte und R\u00fcckfallebene<\/h2>\n\n<p>Vor \u00c4nderungen dokumentiere ich den Ist\u2011Zustand mit <strong>mpstat<\/strong>, htop, <code>\/proc\/interrupts<\/code> und Latenz\u2011Messungen per iperf3. Ich richte Skripte ein, die Affinity\u2011Einstellungen nach einem Reboot oder Treiber\u2011Reload automatisch anwenden. F\u00fcr Rollbacks halte ich neutrale Masken bereit, damit ich bei Fehlverhalten sofort zur\u00fcckschalte. In Staging teste ich Lastprofile, die meiner Produktion m\u00f6glichst nahekommen und wiederhole die <strong>Messung<\/strong> nach jeder Anpassung. Erst dann aktiviere ich das Profil dauerhaft auf dem Zielhost.<\/p>\n\n<h2>H\u00e4ufige Stolpersteine sauber vermeiden<\/h2>\n\n<p>Zu breite Masken verteilen Arbeit \u00fcber zu viele <strong>CPUs<\/strong> und bremsen Caches aus, w\u00e4hrend zu enge Masken Queues verstopfen. Vergessene NUMA\u2011Besonderheiten erzeugen Fernspeicher\u2011Zugriffe, die Antwortzeiten schwanken lassen. Ein hartes Pinning kollidiert gelegentlich mit RPS\/RFS\u2011Einstellungen, daher pr\u00fcfe ich die SoftIRQ\u2011Lastverteilung explizit. Nach Kernel\u2011Updates oder Treiberwechseln validiere ich alle IRQ\u2011Nummern neu, weil sich Zuordnungen \u00e4ndern k\u00f6nnen. Mit vorsichtigen Schritten und klarer <strong>Doku<\/strong> bleibe ich handlungsf\u00e4hig.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux-irq-affinity-network-8347.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kurz zusammengefasst<\/h2>\n\n<p>Gezieltes IRQ\u2011Pinning bindet Netzwerk\u2011Interrupts an wenige passende <strong>Cores<\/strong>, senkt Overhead und stabilisiert Antwortzeiten. Ich stimme dazu IRQ\u2011 und CPU\u2011Affinity ab, beachte NUMA und kontrolliere die Wirkung mit Messreihen. Wo Automatik gen\u00fcgt, lasse ich irqbalance agieren, kritische Queues f\u00fchre ich zu festen Cores. Mit RSS, RPS\/RFS und angepassten Kernel\u2011Parametern entfaltet das Tuning seinen vollen <strong>Effekt<\/strong>. Wer diese Schritte diszipliniert umsetzt, holt auf Multi\u2011Core\u2011Linux\u2011Servern sp\u00fcrbar mehr Netzwerk\u2011Leistung heraus.<\/p>","protected":false},"excerpt":{"rendered":"<p>Descubra como utilizar de forma espec\u00edfica a afinidade de IRQ do Linux em sistemas multiprocessadores, para otimizar a configura\u00e7\u00e3o da rede e a carga da CPU com a palavra-chave \u00abirq affinity\u00bb.<\/p>","protected":false},"author":1,"featured_media":21516,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21523","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"110","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"irq affinity","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21516","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21523","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=21523"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21523\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/21516"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=21523"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=21523"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=21523"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}