Windows Server 2008 UDP Multicast-Leistungsproblem

Bei 2008 R2 Enterprise SP1 tritt ein seltsames Leistungsproblem auf.

Hier ist das Setup:

• Viele Prozesse, die unterschiedliche Multicast-UDP-Streams abhören (5 Multicasts hören pro Prozess ab), sind an eine einzelne Netzwerkkarte gebunden
• Prozessübergreifend verwenden alle Multicasts denselben Portbereich, aber unterschiedliche Multicast-IPs (wichtiges Detail, da jeder Multicast-Empfänger für einen bestimmten Port ein Server des REUSED-Server-Sockets ist).
• Jede Prozess-Multicast-Bandbreite beträgt 10 Mbit
• RSS auf NIC eingestellt, maximale Offload-Einstellungen auf NIC & OS eingestellt, MSI aktiviert

Verhalten:

• Bei 17 Abhörprozessen (ca. 85 verbundene UDP-Multicasts) ist die Auswirkung der Kernel-CPU vernachlässigbar.
• Zwischen 17 und 22 Listenern (ca. 110 verbundene UDP-Multicasts) wächst die CPU-Auslastung des Kernels langsam, ist aber akzeptabel
• Ab 25 Jahren hat jeder verbundene Multicast enorme Auswirkungen auf die Kernel-CPU-Zeit. Dies wirkt sich auf alle RSS-gebundenen CPUs aus
• Die pro Abhörprozess verwendete CPU-Zeit liegt nahe 0 (normal, da Prozesse nur das Multicast lesen), sodass das eigentliche Problem in der Betriebssystemkomponente liegt

Was wir gefunden haben:

• Das Ändern der NIC-Hardware hat keine Auswirkungen auf das Verhalten (Getestet auf HP NC382i, Broadcom-basierter NIC und HP NC365T, Quad Gigabit, Intel-basiert).
• Die globale Empfangsbandbreite ist nicht der begrenzende Faktor (ein einzelner 500-Mbit-Stream löst keine CPU-Last aus).
• Das Lesen am Multicast-Socket scheint nicht der einschränkende Faktor zu sein (wir haben den Test mit nur dummen JOIN-Prozessen für die Multicast-Streams und dem Problem der reproduzierten CPU-Auslastung durchgeführt).
• Das Aufteilen von Multicast-Verkehr auf zwei Netzwerkkarten scheint die CPU-Auslastung und -Verbreitung besser zu begrenzen. Dies ist jedoch kein Anwendungsfall für uns.

Problem:

• Wir müssen mindestens 500 Multicast-Streams und vielleicht bis zu 750 hören können
• Dieselbe Hardware unter XP OS weist dieses Verhalten in der CPU-Kernel-Zeit nicht auf

Ausgewählte Komponente:

• NDIS.sys scheint ein guter Kandidat für die Erklärung des Anstiegs der CPU-Auslastung zu sein.

Hat einer von Ihnen auf solche Probleme gestoßen und könnte eine Richtung zur Untersuchung geben. Ich habe alles gelesen, was ich über die Verbesserung der Netzwerkleistung von Win Server 2008 wissen konnte, aber alle scheinen mit dem TCP-Verkehr verbunden zu sein. Ich habe auch alle möglichen Optimierungen getestet, die über die Registrierung oder den Befehl netsh durchgeführt werden können.

Das sind viele Multicast-Streams. In der Regel haben NICs eine niedrige Grenze für die Hardwarefilterung. Wenn Sie diese überschreiten, löschen sie entweder alles (schlechte Implementierung auf billigen NICs) oder leiten alles an das Betriebssystem weiter, damit es stattdessen gefiltert wird. Wenn das Betriebssystem die Filterung durchführt, wird Ihre Prozessorauslastung in die Höhe schnellen.

Abgesehen von der Untersuchung verschiedener Hardware, von denen Sie einige auflisten, können Sie auch auf 10GigE-Basis erweitern. Die einzige Option ist die Verwendung von Proxyservern.

Durch Experimentieren finden Sie eine Reihe von Multicast-Streams, die zuverlässig verwaltet werden können, und leiten die Streams dann über TCP an einen zentralen Server oder eine Reihe von Servern weiter. Dieser zentrale Server kann dann die TCP-Segmentierungsbeschleunigung oder den vollständigen ToE verwenden, um die eingehende Netzwerklast für den Prozessor unbedeutend zu machen.

Aufgrund der sehr schlechten Windows-Treiber kann ich mit Broadcom-Hardware überhaupt keine angemessenen Multicast-Raten erzielen. Es wäre interessant zu sehen, wie Linux auf derselben Hardware funktioniert, was Ihnen einen guten Hinweis auf die Hardware- und IP-Stack-Qualität geben sollte.

Sie listen Windows XP als einwandfrei auf. Der Hauptunterschied zwischen Windows Server und Windows XP ist die Quantenzeit. Windows Server bietet längere Quantenzeiten. Es könnte sich lohnen, zu untersuchen, ob ein kürzeres Quantum erzwungen werden soll (wenn Sie es überhaupt festlegen können).