Schickt die NIC die Interrupts für eintreffende Pakete nur an einen CPU-Kern, wird dieser Kern zum Engpass.
Warum Nur eine Empfangs-Queue oder RSS (Verteilung auf mehrere Kerne) deaktiviert → Folge Ein Kern läuft auf 100 % und holt Pakete nicht rechtzeitig ab → Auf dem Bildschirm Bei großem Andrang Paketverlust und Latenz auf dem ganzen Server (Teleportieren, Input-Lag)
RSS (Verteilung durch die NIC) und RPS (Verteilung durch den Kernel) konfigurieren, Interrupts auf mehrere Kerne verteilen, für UDP die Queue-Verteilung auch nach Ports einstellen (rx-flow-hash udp4 sdfn bei ethtool -N), Kerne für die Interrupt-Verarbeitung und Kerne für den Tick-Thread des Spiels trennen, %soft pro Kern überwachen.
Größenordnungen
Ein einzelner Kern schafft über den Kernel je nach Paketgröße und Konfiguration grob einige hunderttausend Pakete pro Sekunde. Konzentriert sich in der Auslastung pro Kern der Anteil der Empfangsverarbeitung (%soft in mpstat) auf einen einzigen Kern, liegt dieser Fall vor.
Im Graphen
Plateau am Limit · %soft pro Kern, empfangene Pakete pro Sekunde
Wo nachsehen
Mit mpstat -P ALL 1 %soft pro Kern (Anteil der Software-Interrupt-Verarbeitung) prüfen, in /proc/interrupts nachsehen, an welche Kerne die Interrupts der einzelnen NIC-Queues gehen, mit ethtool -l die Zahl der Queues und mit ethtool -S die Pakete pro Queue prüfen (Namen je nach Treiber verschieden)
Spricht dafür
Nur ein Kern hängt bei %soft dauerhaft nahe 100 %, die übrigen sind frei, Interrupts und Pakete ballen sich in einer Queue. Ab dann steigen die empfangenen Pakete pro Sekunde nicht weiter
Spricht dagegen
%soft gleichmäßig auf mehrere Kerne verteilt: nicht diese Ursache. CPU frei, trotzdem Paketverlust: „Überschrittenes PPS-Limit in der Cloud“ oder „Zu kleiner Ringpuffer“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Auch bei mehreren Queues landet der Traffic in einer einzigen Queue, wenn er größtenteils von wenigen Adressen kommt, etwa von Gateways oder Proxys. Bei UDP verteilt die NIC-Standardeinstellung mitunter nur nach Adressen. Erst wenn auch die Ports einbezogen werden, verteilt sich die Last gleichmäßig.
Quellen
Scaling in the Linux Networking StackLinux kernel RSS (NIC verteilt auf mehrere Empfangs-Queues) und RPS (Kernel verteilt), Konfiguration mit eigenem Interrupt pro Queue, verteilt auf mehrere Kerne, RSS empfohlen, wenn die Verarbeitung von Empfangs-Interrupts der Engpass ist
How to receive a million packets per secondCloudflare Messung: Geht eine Empfangs-Queue nur an einen Kern, stößt dieser bei etwa 350.000–430.000 Paketen pro Sekunde an seine Grenze, Fall einer NIC, die UDP nur nach IP-Adresse hashte, sodass alles in einer Queue landete
ethtool(8) — Linux manual pageethtool Option ethtool -N rx-flow-hash udp4, mit der auch die Ports (f, n) in den UDP-Hash einfließen
mpstat(1) — Linux manual pagesysstat %soft: Anteil der Zeit, den die CPU für Software-Interrupts aufwendet, pro Kern mit -P ALL