Welche Netzwerklasten erfordern NIC-Abfragen im Vergleich zu Interrupts?

18

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?

Wim Kerkhoff
quelle
Muss eine schwierige Frage sein ... Danke für das Kopfgeld, @Holocryptic! Ich habe einige "ethtool -c" -Einstellungen zum Zusammenführen ausprobiert, aber noch keine bemerkenswerten Unterschiede.
Wim Kerkhoff
Kein Problem. Ich sah es nur ein paar Tage dort verweilen und es schien eine gute Frage zu sein. Hoffentlich hat jemand etwas für dich.
Holocryptic
Ein weiteres Update ... Wir sind auf IBM HS23-Blades mit Emulex 10-Gbit / s-Netzwerkkarten umgestiegen. Diese Woche haben wir über 800.000 Pakete / Sekunde erreicht, keine Tropfen. Wir mussten viel tunen (Patchen von Linux-Kerneltreibern), um die Last der IRQs auszugleichen, aber es funktioniert jetzt fantastisch.
Wim Kerkhoff

Antworten:

6

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.

DictatorBob
quelle
Hier einige nützliche Hintergrundinformationen: alexonlinux.com/…
DictatorBob
1
Ich stimme der grundsätzlichen Aussage zu "Ja, sollte keine Probleme haben", aber da sie Probleme haben, ist es wahrscheinlich ein Firmware- oder Treiberproblem. Ich habe meine Workstation überhaupt nicht "abgestimmt" und sie kann 65kips ziehen, ohne ins Schwitzen zu geraten. 15 Kips sollten für eine moderne CPU nichts sein. Ich verwende ausschließlich Broadcom-Netzwerkkarten, wobei die 5709 die mit Abstand am häufigsten verwendete ist. Dieser Test wurde unter FreeBSD ausgeführt, jedoch nicht unter Linux.
Chris S
Danke für die Ideen. Ich habe Irqbalance ausprobiert, aber keinen Unterschied bemerkt. Ich habe mit mehr Coalesce-Einstellungen (ethtool -c) gespielt, aber keinen Unterschied bemerkt. Eines der Blades ist der Load Balancer, der bis zu 120.000 Pakete pro Sekunde überträgt. Ich habe festgestellt, dass die CPU-Auslastung von ksoftirqd auf 100% steigt, wenn die NAT- und conntrack-Iptables geladen sind. Entladen Sie diese Module und laden Sie die Drops auf 0. Auf den Squid-Servern (max. 10.000 Pakete / Sek.) Habe ich die 17.000 (!!!) iptables-Regeln gelöscht, und die Latenzen sind sofort gesunken. Ich dachte, ich hätte das schon einmal versucht, aber anscheinend nicht ...
Wim Kerkhoff
3

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.

Chopper3
quelle
1

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.

Core-Dump
quelle
1

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.

Chris S
quelle
1

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.

Wim Kerkhoff
quelle
Nur ein weiteres Update. Vor kurzem hat sich die Leistung ohne ersichtlichen Grund erneut verschlechtert. Wir haben alle vorherigen Optimierungen ohne Erfolg überprüft. Intel-Netzwerkkarten sind immer noch keine wirtschaftliche Option (Investition von 30 bis 40.000 US-Dollar in neue Interconnects, 10-GB-Switches usw.). ABER, wir haben einige etwas neuere IBM HS22-Blades gefunden, die immer noch den beschissenen bnx2 verwenden, aber mit neuerer Firmware. Die Leistung ist viel besser - wir haben die Grenze von 150.000 Paketen / Sek. Überschritten.
Wim Kerkhoff