Frage Warum ist TCP accept () so schlecht unter Xen?


Die Rate, mit der mein Server neue eingehende TCP-Verbindungen akzeptieren kann, ist unter Xen wirklich schlecht. Der gleiche Test auf Bare-Metal-Hardware zeigt 3-5x Beschleunigungen.

  1. Wieso ist das unter Xen so schlimm?
  2. Können Sie Xen optimieren, um die Leistung für neue TCP-Verbindungen zu verbessern?
  3. Gibt es andere Virtualisierungsplattformen, die für diesen Anwendungsfall besser geeignet sind?

Hintergrund

In letzter Zeit untersuche ich einige Performance-Engpässe eines selbst entwickelten Java-Servers, der unter Xen läuft. Der Server spricht HTTP und beantwortet einfache TCP-Verbindungs- / Anfrage- / Antwort- / Verbindungsaufrufe.

Aber selbst beim Senden von Schiffsladungen an den Server kann es nicht mehr als ca. 7000 TCP-Verbindungen pro Sekunde akzeptieren (auf einer 8-Core-EC2-Instanz, c1.xlarge läuft unter Xen). Während des Tests zeigt der Server auch ein seltsames Verhalten, bei dem ein Kern (nicht notwendigerweise CPU 0) sehr stark> 80% geladen wird, während die anderen Kerne fast leer bleiben. Dies führt mich zu der Annahme, dass das Problem mit dem Kernel / der zugrunde liegenden Virtualisierung zusammenhängt.

Beim Testen des gleichen Szenarios auf einer nicht-virtualisierten Bare-Metal-Plattform erhalte ich Testergebnisse, die TCP accept () Raten über 35 000 / Sekunde hinaus zeigen. Dies auf einem Core i5 4 Core-Rechner, auf dem Ubuntu läuft und alle Kerne fast vollständig ausgelastet sind. Für mich scheint diese Art von Figur in Ordnung zu sein.

Auch auf der Xen-Instanz habe ich versucht, fast alle Einstellungen in sysctl.conf zu aktivieren / zu optimieren. Einschließlich Aktivierung Paketlenkung erhalten und Flow-Lenkung erhalten und Festhalten von Threads / Prozessen an CPUs, jedoch ohne erkennbare Vorteile.

Ich weiß, dass eine herabgesetzte Leistung zu erwarten ist, wenn virtualisiert ausgeführt wird. Aber in diesem Maße? Ein langsamer, Bare-Metal-Server, der virt übertrifft. 8-Kern um den Faktor 5?

  1. Ist das wirklich erwartetes Verhalten von Xen?
  2. Können Sie Xen optimieren, um die Leistung für neue TCP-Verbindungen zu verbessern?
  3. Gibt es andere Virtualisierungsplattformen, die für diesen Anwendungsfall besser geeignet sind?

Reproduzieren dieses Verhaltens

Als ich das weiter untersuchte und das Problem ausfindig machte, fand ich heraus, dass die Netperf Leistungstest-Tool könnte das ähnliche Szenario, das ich erlebe, simulieren. Mit dem TCP_CRR-Test von netperf habe ich verschiedene Berichte von verschiedenen Servern (sowohl virtualisiert als auch nicht-virtuell) gesammelt. Wenn Sie mit einigen Ergebnissen beitragen oder meine aktuellen Berichte nachschlagen möchten, sehen Sie bitte https://gist.github.com/985475

Woher weiß ich, dass dieses Problem nicht auf schlecht geschriebene Software zurückzuführen ist?

  1. Der Server wurde auf Bare-Metal-Hardware getestet und es erfüllt nahezu alle ihm zur Verfügung stehenden Kerne.
  2. Wenn Keep-Alive-TCP-Verbindungen verwendet werden, verschwindet das Problem.

Warum ist das wichtig?

Beim ESN (mein Arbeitgeber) Ich bin der Projektleiter von Beaconpushein Comet / Web Socket Server, der in Java geschrieben ist. Obwohl es sehr performant ist und fast jede Bandbreite unter optimalen Bedingungen sättigen kann, ist es immer noch darauf beschränkt, wie schnell neue TCP-Verbindungen hergestellt werden können. Das heißt, wenn Sie eine große Benutzerabwanderung haben, bei der Benutzer sehr oft kommen und gehen, müssen viele TCP-Verbindungen eingerichtet / abgebaut werden. Wir versuchen, diese Verbindungen so lange wie möglich am Leben zu halten. Aber am Ende ist die accept () - Leistung, die unsere Kerne davon abhält, sich zu drehen, und das gefällt uns nicht.


Update 1

Jemand hat diese Frage zu Hacker News gepostetDa gibt es auch einige Fragen / Antworten. Aber ich werde versuchen, diese Frage mit den Informationen, die ich finde, auf dem neuesten Stand zu halten.

Hardware / Plattformen, an denen ich das getestet habe:

  • EC2 mit Instanztypen c1.xlarge (8 Kerne, 7 GB RAM) und cc1.4xlarge (2x Intel Xeon X5570, 23 GB RAM). AMIs, die verwendet wurden, waren ami-08f40561 bzw. ami-1cad5275. Jemand wies auch darauf hin, dass die "Sicherheitsgruppen" (d. H. Die EC2-Firewall) ebenfalls betroffen sein könnten. Aber für dieses Testszenario habe ich nur auf localhost versucht, externe Faktoren wie diese zu eliminieren. Ein anderes Gerücht, das ich gehört habe, ist, dass EC2 Instanzen nicht mehr als 100k PPS drücken können.
  • Zwei private virtualisierte Server, auf denen Xen ausgeführt wird. Man hatte vor dem Test keine Last, aber keinen Unterschied.
  • Privater dedizierter Xen-Server bei Rackspace. Über dieselben Ergebnisse dort.

Ich bin dabei, diese Tests erneut durchzuführen und die Berichte bei https://gist.github.com/985475 Wenn Sie helfen möchten, tragen Sie Ihre Zahlen ein. Es ist einfach!

(Der Aktionsplan wurde in eine separate, konsolidierte Antwort verschoben)


87
2018-05-22 16:39


Ursprung


Ausgezeichnete Arbeit, die auf ein Problem hinweist, aber ich glaube, dass Sie viel besser auf einer Xen-spezifischen Mailingliste, einem Support-Forum oder sogar der Xensource Fehlerbericht Website. Ich glaube, das könnte ein Scheduler-Bug sein - wenn Sie Ihre Anzahl von 7.000 Verbindungen * 4 Kerne / 0.80 CPU-Last nehmen, erhalten Sie genau 35.000 - die Zahl, die Sie bekommen würden, wenn 4 Kerne vollständig gesättigt wären. - the-wabbit
Ah, und noch etwas: versuchen Sie eine andere (vielleicht neuere) Kernel-Version für Ihren Gast, wenn Sie können. - the-wabbit
@syneticon-dj Danke. Ich habe es mit einer cc1.4xlarge bei EC2 mit Kernel 2.6.38 versucht. Ich habe etwa 10% mehr gesehen, wenn ich mich nicht irre. Aber es ist wahrscheinlicher wegen der kräftigeren Hardware dieses Instanztyps. - cgbystrom
Danke, dass Sie dies mit den Antworten von HN auf dem Laufenden halten, es ist eine großartige Frage. Ich schlage vor, den Aktionsplan in eine konsolidierte Antwort zu übertragen, möglicherweise - da dies alles mögliche Antworten auf das Problem sind. - Jeff Atwood
@jeff Verschieben Sie den Aktionsplan, überprüfen Sie. - cgbystrom


Antworten:


Gerade jetzt: Kleine Paketleistung saugt unter Xen

(stattdessen von der Frage selbst zu einer separaten Antwort übergegangen)

Laut einem Benutzer auf HN (ein KVM-Entwickler?) Ist dies auf kleine Paketleistung in Xen und KVM zurückzuführen. Es ist ein bekanntes Problem mit der Virtualisierung, und laut ihm geht VMWare's ESX viel besser damit um. Er stellte außerdem fest, dass KVM einige neue Funktionen enthält, dieursprünglicher Beitrag).

Diese Information ist etwas entmutigend, wenn sie korrekt ist. Wie auch immer, ich werde die folgenden Schritte versuchen, bis ein Xen-Guru mit einer definitiven Antwort kommt :)

Iain Kay von der Xen-Users-Mailingliste hat dieses Diagramm erstellt: netperf graph Beachten Sie die TCP_CRR-Balken, vergleichen Sie "2.6.18-239.9.1.el5" vs "2.6.39 (mit Xen 4.1.0)".

Aktueller Aktionsplan basierend auf Antworten / Antworten hier und von HN:

  1. Übermitteln Sie dieses Problem an eine Xen-spezifische Mailing-Liste und das Xensource-Bugzilla, wie von Syneticon-DJ vorgeschlagen EIN Nachricht wurde in der Xen-Benutzerliste veröffentlicht, Antwort abwarten.

  2. Erstellen Sie einen einfachen pathologischen Testfall auf Anwendungsebene, und veröffentlichen Sie ihn.
    Ein Testserver mit Anweisungen wurde erstellt und veröffentlicht in GitHub. Damit sollten Sie im Vergleich zu netperf einen realistischeren Anwendungsfall sehen können.

  3. Versuchen Sie eine 32-Bit-PV-Xen-Gastinstanz, da 64-Bit in Xen möglicherweise mehr Overhead verursacht. Jemand hat das auf HN erwähnt. Hat keinen Unterschied gemacht.

  4. Versuchen Sie net.ipv4.tcp_syncookies in sysctl.conf zu aktivieren, wie von abofh auf HN vorgeschlagen. Dies anscheinend könnte Verbessern Sie die Leistung, da der Handshake im Kernel stattfinden würde. Ich hatte damit kein Glück.

  5. Erhöhen Sie den Rückstand von 1024 auf etwas viel höher, auch von abofh auf HN vorgeschlagen. Dies könnte auch hilfreich sein, da der Gast möglicherweise während der von dom0 (dem Host) gegebenen Ausführungs-Slice weitere Verbindungen akzeptieren kann.

  6. Überprüfen Sie, ob Conntrack auf allen Rechnern deaktiviert ist, da es die Akzeptanzrate halbieren kann (vorgeschlagen von debeulyou). Ja, es wurde in allen Tests deaktiviert.

  7. Suchen Sie nach "listen queue overflow und syncache Buckets Überlauf in netstat -s" (vorgeschlagen von mike_esspe on HN).

  8. Teilen Sie die Interrupt-Behandlung unter mehreren Kernen auf (RPS / RFS, die ich zuvor aktiviert hatte, sollte dies tun, könnte aber einen erneuten Versuch wert sein). Vorgeschlagen von adamt bei HN.

  9. Abschalten der TCP-Segmentierung und Scatter / Gather-Beschleunigung, wie von Matt Bailey vorgeschlagen. (Nicht möglich auf EC2 oder ähnlichen VPS Hosts)


26
2018-05-22 23:41



+1 Veröffentlichen Sie die Leistungsergebnisse, wenn Sie es herausgefunden haben! - chrisaycock
Jemand hat mich auf Twitter zu dieser Frage angesprochen. Leider scheint es, als ob diese Probleme bestehen bleiben. Ich habe seit dem letzten Jahr nicht viel Forschung betrieben. Xen MAY hat sich in dieser Zeit verbessert, ich weiß es nicht. Der KVM-Entwickler erwähnte auch, dass sie solche Probleme ansprechen. Könnte es wert sein, verfolgt zu werden. Auch eine andere Empfehlung, die ich gehört habe, ist, OpenVZ anstelle von Xen / KVM zu versuchen, da es weniger oder kein Layering / interception von syscalls hinzufügt. - cgbystrom


Anekdotisch habe ich festgestellt, dass das Ausschalten der NIC-Hardwarebeschleunigung die Netzwerkleistung auf dem Xen-Controller erheblich verbessert (gilt auch für LXC):

Scatter-Gather-Beschleunigung:

/usr/sbin/ethtool -K br0 sg off

TCP-Segmentierungsoffload:

/usr/sbin/ethtool -K br0 tso off

Dabei ist br0 Ihre Bridge oder Ihr Netzwerkgerät auf dem Hypervisor-Host. Sie müssen dies einrichten, um es bei jedem Start zu deaktivieren. YMMV.


20
2018-05-22 19:09



Ich unterstütze das. Ich hatte einen Windows 2003 Server, der auf Xen lief, der unter hohen Durchsatzbedingungen einige schreckliche Paketverlustprobleme hatte. Das Problem verschwand, als ich das TCP-Segment-Offload deaktivierte - rupello
Vielen Dank. Ich habe den "Aktionsplan" in der ursprünglichen Frage mit Ihren Vorschlägen aktualisiert. - cgbystrom
siehe auch cloudnull.io/2012/07/xenserver-network-tuning - Lari Hotari


Vielleicht könntest du ein bisschen klären - hast du die Tests unter Xen auf deinem eigenen Server oder nur auf einer EC2 Instanz ausgeführt?

Accept ist nur ein weiterer Syscall und neue Verbindungen unterscheiden sich nur dadurch, dass die ersten paar Pakete bestimmte Flags haben - ein Hypervisor wie Xen sollte definitiv keinen Unterschied sehen. Andere Teile Ihres Setups könnten: In EC2 zum Beispiel wäre ich nicht überrascht, wenn Sicherheitsgruppen etwas damit zu tun hätten; Conntrack ist auch berichtet, um neue Verbindungen zu halbieren akzeptieren Rate (PDF).

Zu guter Letzt scheint es CPU / Kernel-Kombinationen zu geben, die merkwürdige CPU-Auslastung / -Halten auf EC2 (und wahrscheinlich Xen im Allgemeinen) verursachen kürzlich von Librato gebloggt.


2
2018-05-22 19:56



Ich habe die Frage aktualisiert und geklärt, auf welcher Hardware ich das versucht habe. abofh schlug auch vor, den Rückstand über 1024 hinaus zu erhöhen, um die Anzahl möglicher accept () s während einer Ausführungsscheibe für den Gast zu erhöhen. In Bezug auf Conntrack, ich sollte auf jeden Fall überprüfen, dass solche Dinge deaktiviert sind, danke. Ich habe diesen Liberato-Artikel gelesen, aber angesichts der Menge verschiedener Hardware, die ich ausprobiert habe, sollte das nicht der Fall sein. - cgbystrom


Stellen Sie sicher, dass Sie iptables und andere Hooks im Bridging-Code in dom0 deaktiviert haben. Offensichtlich gilt es nur für Bridge-Networking-Xen-Setup.

echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 0 > /proc/sys/net/bridge.bridge-nf-call-arptables

Es hängt von der Größe des Servers ab, aber kleineren (4-Core-Prozessor) widmen Sie einen CPU-Kern Xen Dom0 und stecken Sie es fest. Hypervisor-Startoptionen:

dom0_max_vcpus=1 dom0_vcpus_pin dom0_mem=<at least 512M>

Haben Sie versucht, ein physisches Ethernet-PCI-Gerät an domU zu übergeben? Es sollte einen schönen Leistungsschub geben.


0
2018-02-11 11:35