Wie verteilt Receive-Side Scaling die Netzwerkbelastung eines Heimservers?

Receive-Side Scaling verteilt die Netzwerklast eines Heimservers, indem eingehende Datenströme in mehrere NIC-Empfangswarteschlangen gehasht und diese Warteschlangen verschiedenen CPU-Kernen zugeordnet werden. Anstatt dass ein Kern fast alle Empfangsunterbrechungen und Protokollaufgaben übernimmt, können mehrere Kerne unabhängige Verbindungen parallel verarbeiten.

RSS ist besonders nützlich, wenn der Server genügend Pakete empfängt, sodass ein Kern zum Engpass wird. Es macht eine einzelne Festplatte nicht schneller, erhöht nicht die Netzwerkkapazität und teilt einen gewöhnlichen TCP-Datenstrom nicht gleichmäßig auf alle Kerne auf. Seine Aufgabe ist es, einen Engpass bei der Paketverarbeitung zu beseitigen und dabei die Reihenfolge der Datenströme beizubehalten.

Der Kernmechanismus: Mehrere Empfangswarteschlangen versorgen mehrere Kerne

Ohne Multi-Queue-Empfangsverarbeitung kann eine schnelle NIC Arbeit an einen Interrupt-Pfad schneller liefern, als ein CPU-Kern sie bearbeiten kann. Die Gesamt-CPU-Auslastung mag gering erscheinen, weil die anderen Kerne untätig sind, doch der Durchsatz stagniert und die Netzwerklatenz steigt beim überlasteten Kern.

RSS nutzt mehrere Empfangswarteschlangen, sodass eingehende Datenströme gleichzeitig verarbeitet werden können. Jede Warteschlange erzeugt ihren eigenen Interrupt und Verarbeitungsweg, wodurch das Betriebssystem mehr der bereits vorhandenen CPU-Ressourcen nutzen kann.

Das ist wichtig bei einem Heimserver, der gleichzeitig Dateifreigabe, Medienstreams, Backups und Container-Apps betreibt. Diese unabhängigen Verbindungen liefern die parallele Arbeit, die RSS benötigt; ein wenig genutzter 1GbE-Anschluss erzeugt möglicherweise nie genug Paketdruck, damit der Unterschied sichtbar wird.

Flow-Hashing bewahrt die Reihenfolge und verteilt Verbindungen

Die NIC berechnet einen Hash aus Paketkopf-Feldern wie Quell- und Zieladressen, Ports und Protokoll. Eine Indirektionstabelle ordnet diesen Hash einer Empfangswarteschlange zu. Pakete desselben Datenstroms erreichen normalerweise dieselbe Warteschlange, wodurch parallele Verarbeitung die Reihenfolge dieses Datenstroms nicht verändert.

Die Beziehung zwischen RSS, IRQ-Affinität und RPS bestimmt, wo die Arbeit unter Linux tatsächlich ausgeführt wird. Hardware-RSS wählt eine Empfangswarteschlange; Interrupt-Affinität verbindet diese Warteschlange mit einer CPU; Software-Steuerung kann spätere Protokollarbeit umverteilen, wenn Hardware-Warteschlangen begrenzt sind.

Hashing verteilt viele Datenströme statistisch, aber nicht perfekt. Einige wenige starke Datenströme können in einer Warteschlange kollidieren, und ein einzelner dominanter Datenstrom kann an einen Kern gebunden bleiben. Deshalb sind Beobachtungen pro Kern und pro Warteschlange nützlicher, als davon auszugehen, dass eine Mehrkern-CPU automatisch eine gleichmäßige Netzwerklast garantiert.

Mehr Warteschlangen können Engpassentlastung gegen CPU-Overhead tauschen

Eine höhere Anzahl von Warteschlangen schafft mehr Möglichkeiten für Parallelität, erzeugt aber auch mehr Interrupts, Planungsaufwand und Cache-Bewegungen. Die optimale Anzahl hängt von der NIC-Fähigkeit, der CPU-Topologie, der Verkehrsrate und davon ab, ob die Anwendungen, die Pakete verarbeiten, nahe an der Empfangsverarbeitung laufen.

Eine praktische Erklärung von Single-Core-Empfangssättigung zeigt, warum die Gesamt-CPU-Auslastung das eigentliche Limit verbergen kann. Der nützliche Test ist, ob ein Kern durch Interrupts oder Softirq-Arbeit ausgelastet ist, während andere Kerne noch Kapazitäten haben.

RSS kann auch den Overhead erhöhen, wenn der Datenverkehr zu gering ist, um es zu benötigen. Parallele Paketverteilung verbessert die Skalierung, aber die Platzierung der Warteschlangen und die Flow-zu-Kern-Lokalität beeinflussen weiterhin die Effizienz. Daher ist das Aktivieren aller möglichen Warteschlangen keine universelle Optimierung.

Wie RSS einen Engpass im Heimserver verändert

RSS hilft, wenn der Empfangspfad CPU-begrenzt ist: Ein Kern zeigt hohe Netzwerkverarbeitungsbelastung, mehrere Clients sind aktiv und der Speicher hat noch Kapazität. Es hilft nicht, wenn der Ethernet-Anschluss ausgelastet ist, die Festplatten die Last nicht tragen können, Verschlüsselung die CPU-Zeit dominiert oder eine Anwendung alle Anfragen seriell verarbeitet.

Vergleichen Sie NIC-Warteschlangenzähler, Interrupt-Last pro Kern, Durchsatz und Anwendungslatenz vor und nach einer kontrollierten Änderung. Ein umfassenderer Heimserver-Engpass-Check hilft, zu verhindern, dass eine Netzwerktuning-Änderung einen Speicher-, Speicher- oder Rechenengpass verdeckt.

Häufig gestellte Fragen

Teilt RSS eine TCP-Verbindung auf alle Kerne auf?

Normalerweise nicht. RSS hält Pakete eines Datenstroms in derselben Warteschlange, um die Reihenfolge zu bewahren. Der Skalierungsvorteil zeigt sich am deutlichsten, wenn mehrere unabhängige Datenströme über mehrere Warteschlangen gehasht werden können.

Ist RSS auf einem 1GbE-Heimserver nützlich?

Es kann nützlich sein, besonders bei vielen kleinen Paketen oder einer stromsparenden CPU, aber viele Systeme können 1GbE auf einem Kern verarbeiten. Messen Sie die Last pro Kern, bevor Sie RSS als fehlendes Leistungsmerkmal betrachten.

Sind RSS und RPS dasselbe?

Nein. RSS steuert Pakete in der NIC-Hardware zu Empfangswarteschlangen, während Receive Packet Steering einen verwandten Verteilungsschritt in der Software durchführt. Sie können sich ergänzen, wenn die Anzahl der Hardware-Warteschlangen begrenzt ist.