Welche Netzwerklasten erfordern NIC-Abfragen im Vergleich zu Interrupts?

Hat jemand Daten oder grundlegende Berechnungen, die beantworten können, wenn Frame Coalescing (NAPI) erforderlich ist und ein einzelner Interrupt pro Frame ausreicht?

Meine Hardware: IBM BladeServer HS22, Broadcom 5709 Gigabit-NIC-Hardware (MSI-X) mit zwei Xeon E5530-Quad-Core-Prozessoren. Hauptzweck ist der Squid-Proxy-Server. Switch ist eine schöne Cisco 6500-Serie.

Unser Hauptproblem ist, dass in Spitzenzeiten (100 Mbit / s, nur 10.000 pps) die Latenz und der Paketverlust zunehmen. Ich habe eine Menge Tuning und Kernel-Upgrade auf 2.6.38 durchgeführt und es hat den Paketverlust verbessert, aber die Latenz ist immer noch schlecht. Pings sind sporadisch; Springen sogar auf 200 ms im lokalen Gbit / s-LAN. Die durchschnittliche Squid-Antwort springt von 30 ms auf über 500 ms, obwohl die CPU- / Speicherlast in Ordnung ist.

Die Interrupts steigen während der Spitze auf ungefähr 15.000 / Sekunde. Ksoftirqd verbraucht nicht viel CPU. Ich habe irqbalance installiert, um die IRQs (jeweils 8 für eth0 und eth1) auf alle Kerne zu verteilen, aber das hat nicht viel geholfen.

Intel-NICs scheinen diese Art von Problemen nie zu haben, aber aufgrund des Bladesystems und der festen Konfigurationshardware bleiben wir bei den Broadcoms hängen.

Alles deutet darauf hin, dass der NIC der Hauptschuldige ist. Die beste Idee, die ich derzeit habe, ist es, die Interrupts zu verringern und gleichzeitig die Latenz und den Durchsatz hoch zu halten.

Das bnx2 unterstützt leider weder adaptive-rx noch tx.

Die Thread-Antwort NAPI vs Adaptive Interrupts bietet einen umfassenden Überblick über die Interrupt-Moderation, enthält jedoch keine konkreten Informationen zur Berechnung der optimalen ethtool-Koalesce-Einstellungen für eine bestimmte Problemumgehung. Gibt es einen besseren Ansatz als nur Versuch und Irrtum?

Benötigt die oben erwähnte Workload- und Hardwarekonfiguration überhaupt NAPI? Oder sollte es in der Lage sein, von einem einzelnen Interrupt pro Paket zu leben?

Tolle Frage, bei der ich etwas lesen musste, um es herauszufinden. Ich wünschte, ich könnte sagen, ich hätte eine Antwort ... aber vielleicht ein paar Tipps.

Ich kann zumindest Ihre Frage beantworten, "sollte es in der Lage sein, von einem einzelnen Interrupt pro Paket zu leben". Ich denke, die Antwort lautet "Ja", basierend auf einer stark ausgelasteten Firewall, auf die ich Zugriff habe:

Sar-Ausgabe:

03:04:53 PM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
03:04:54 PM        lo     93.00     93.00      6.12      6.12      0.00      0.00      0.00
03:04:54 PM      eth0 115263.00 134750.00  13280.63  41633.46      0.00      0.00      5.00
03:04:54 PM      eth8  70329.00  55480.00  20132.62   6314.51      0.00      0.00      0.00
03:04:54 PM      eth9  53907.00  66669.00   5820.42  21123.55      0.00      0.00      0.00
03:04:54 PM     eth10      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:04:54 PM     eth11      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:04:54 PM      eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:04:54 PM      eth2 146520.00 111904.00  45228.32  12251.48      0.00      0.00     10.00
03:04:54 PM      eth3    252.00  23446.00     21.34   4667.20      0.00      0.00      0.00
03:04:54 PM      eth4      8.00     10.00      0.68      0.76      0.00      0.00      0.00
03:04:54 PM      eth5      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:04:54 PM      eth6   3929.00   2088.00   1368.01    183.79      0.00      0.00      1.00
03:04:54 PM      eth7     13.00     17.00      1.42      1.19      0.00      0.00      0.00
03:04:54 PM     bond0 169170.00 201419.00  19101.04  62757.00      0.00      0.00      5.00
03:04:54 PM     bond1 216849.00 167384.00  65360.94  18565.99      0.00      0.00     10.00

Wie Sie sehen, werden einige sehr hohe Pakete pro Sekunde gezählt, und auf dieser Maschine wurde kein spezielles Ethtool-Tweaking durchgeführt. Oh ... Intel-Chipsatz. : \

Das einzige, was getan wurde, war ein manueller IRQ-Ausgleich mit / proc / irq / XXX / smp_affinity auf einer Basis pro Schnittstelle. Ich bin mir nicht sicher, warum sie diesen Weg gewählt haben, anstatt mit Ungleichgewicht, aber es scheint zu funktionieren.

Ich habe auch über die Mathematik nachgedacht, die zur Beantwortung Ihrer Frage erforderlich ist, aber ich denke, es gibt viel zu viele Variablen. Zusammenfassend lässt sich sagen, dass die Antwort meiner Meinung nach "Nein" lautet. Ich glaube, Sie können die Ergebnisse hier nicht vorhersagen, aber mit einer ausreichenden Datenerfassung sollten Sie in der Lage sein, sie auf ein besseres Niveau zu bringen.

Trotzdem habe ich das Gefühl, dass Sie irgendwie an die Hardware gebunden sind ... wie bei einer Firmware oder einem Interop-Bug.

Angesichts der CPU-, Chipsatz- und Busfähigkeiten im Vergleich zu einem so geringen Verkehrsaufkommen gibt es für Sie sicherlich keinen Grund, eine Form von Interrupt-Management zu BRAUCHEN. Wir haben mehrere RHEL 5.3 64-Bit-Computer mit 10-Gbit / s-NICs und ihre Interrupts sind gar nicht so schlecht, das ist 100-mal weniger.

Offensichtlich haben Sie eine feste Konfiguration (ich verwende HP Blades, die ziemlich ähnlich sind), so dass das Austauschen von Netzwerkkarten gegen Intel jetzt eine einfache Option ist mit diesem bestimmten Broadcom NIC. Die SE-Sites selbst hatten Probleme mit dieser Art von Inkonsistenz, und der Austausch zu Intel-NICs hat absolut geholfen.

Was ich empfehlen würde, ist ein einzelnes Blade auszuwählen und diesem einen Intel-basierten Adapter hinzuzufügen. Sie müssen natürlich eine Verbindung hinzufügen oder wie auch immer IBM sie nennt, um das Signal auszugeben, aber versuchen Sie dasselbe Software-Setup, aber mit diesem anderen NIC (Deaktivieren Sie wahrscheinlich Broadcom, wenn Sie können). Testen Sie dies und sehen Sie, wie Sie zurechtkommen. Ich weiß, dass das, was ich beschrieben habe, ein paar zusätzliche Hardware-Teile benötigt, aber ich kann mir vorstellen, dass Ihr IBM-Mitarbeiter Ihnen diese gerne ausleiht. Nur so können Sie sicher sein. Bitte lassen Sie uns wissen, was Sie herausfinden. Ich bin wirklich interessiert, wenn es ein Problem mit diesen NICs gibt, auch wenn es sich um einen Sonderfall handelt. Abgesehen davon treffe ich mich nächste Woche mit Intel und Broadcom, um etwas völlig anderes zu besprechen, aber ich werde es auf jeden Fall mit ihnen besprechen und Sie wissen lassen, wenn ich etwas von Interesse finde.

Die Frage nach Interrupts ist, wie sie sich auf die Gesamtsystemleistung auswirken. Interrupts können die Verarbeitung von Benutzer- und Kernel-Land verhindern, und obwohl Sie möglicherweise nicht viel CPU-Auslastung feststellen, kommt es zu vielen Kontextwechseln, und das ist ein großer Leistungseinbruch. Sie können vmstatdie systemSpalte, die csÜberschrift für die Interrupts und die Kontextwechsel pro Sekunde verwenden und überprüfen (Interrupts enthalten die Uhr, sodass Sie diese einschätzen müssen). Dies ist ebenfalls eine Überprüfung wert.

Die kurze direkte Antwort:

Wenn Sie das Abrufen aktivieren, reduzieren Sie die Kontextwechsel (normalerweise aufgrund von Unterbrechungen) von jetzt (15kips in Ihrem Fall) auf eine festgelegte Zahl (normalerweise 1k bis 2k).

Wenn Sie derzeit Datenverkehr über der festgelegten Anzahl haben, sollten Sie bessere Antwortzeiten haben, indem Sie die Abfrage aktivieren. Das Gegenteil ist auch wahr. Ich würde nicht sagen, dass dies "notwendig" ist, es sei denn, die Kontextwechsel wirken sich auf die Leistung aus.

Im Nachhinein: Mit den entladenen NAT- und Conntrack-Modulen und dem minimierten Iptables-Regelsatz erhalten wir eine hervorragende Leistung. Der IPVS-Load-Balancer hat über 900 Mbit / s / 150 Kpps erreicht. Dies ist, während immer noch die gleichen Broadcom BNX2-Chipsätze verwendet.

Abschließend: Die Interrupt-Behandlung scheint in Ordnung zu sein und die Standardeinstellungen für Debian mit 2.6.38 / 3.0.x Kernel scheinen akzeptabel zu sein.

Auf jeden Fall würde ich Intel-Netzwerkkarten vorziehen, damit wir Standard-Debian-Pakete verwenden können. Der Kampf gegen die unfreie BNX2-Firmware war eine enorme Zeitverschwendung.