So optimieren Sie die TCP-Leistung unter Linux mit einer 10-Gbit-Glasfaserverbindung

7

Wir haben 2 Red Hat Server, die für den Speedtest von Kunden vorgesehen sind. Beide verwenden 10-Gbit-Glasfaserverbindungen und sitzen auf 10-Gbit-Verbindungen. Alle Netzwerkgeräte zwischen diesen Servern unterstützen 10 Gbit / s. Mit Iperf oder Iperf3 kann ich nur 6,67 Gbit / s erreichen. Davon abgesehen ist ein Server in Produktion (Kunden treffen ihn) und der andere Server ist online, wird aber nicht verwendet. (Wir verwenden es zum Testen von atm) Die 6,67 Gbit / s sind auch eine Möglichkeit, die ich erwähnen sollte. Wir nennen diese Server A und Server B.

Wenn Server A als iperf-Server fungiert, erhalten wir die Geschwindigkeit von 6,67 Gbit / s. Wenn Server A als Client zu Server B fungiert, kann er nur etwa 20 MBit / s übertragen.

Was habe ich getan:

Bisher habe ich nur die TX / RX-Puffer auf beiden Servern auf das Maximum erhöht. Einer war auf 512 eingestellt, der andere auf 453. (Nur RX, TX wurde bereits ausgereizt). Hier ist also, dass dies nach dem Update bei beiden so aussieht:

Server A:
Ring parameters for em1:
Pre-set maximums:
RX:     4096
RX Mini:    0
RX Jumbo:   0
TX:     4096
Current hardware settings:
RX:     4096
RX Mini:    0
RX Jumbo:   0
TX:     4096

Server B:
Ring parameters for p1p1:
Pre-set maximums:
RX:     4078
RX Mini:    0
RX Jumbo:   0
TX:     4078
Current hardware settings:
RX:     4078
RX Mini:    0
RX Jumbo:   0
TX:     4078

NICS sieht folgendermaßen aus:

Server A: 
ixgbe 0000:01:00.0: em1: NIC Link is Up 10 Gbps, Flow Control: RX/TX

Serer B:
bnx2x 0000:05:00.0: p1p1: NIC Link is Up, 10000 Mbps full duplex,     Flow control: ON - receive & transmit

Server A ethtool stats:
 rx_errors: 0
 tx_errors: 0
 rx_over_errors: 0
 rx_crc_errors: 0
 rx_frame_errors: 0
 rx_fifo_errors: 0
 rx_missed_errors: 0
 tx_aborted_errors: 0
 tx_carrier_errors: 0
 tx_fifo_errors: 0
 tx_heartbeat_errors: 0
 rx_long_length_errors: 0
 rx_short_length_errors: 0
 rx_csum_offload_errors: 123049

 Server B ethtool stats:
 [0]: rx_phy_ip_err_discards: 0
 [0]: rx_csum_offload_errors: 0
 [1]: rx_phy_ip_err_discards: 0
 [1]: rx_csum_offload_errors: 0
 [2]: rx_phy_ip_err_discards: 0
 [2]: rx_csum_offload_errors: 0
 [3]: rx_phy_ip_err_discards: 0
 [3]: rx_csum_offload_errors: 0
 [4]: rx_phy_ip_err_discards: 0
 [4]: rx_csum_offload_errors: 0
 [5]: rx_phy_ip_err_discards: 0
 [5]: rx_csum_offload_errors: 0
 [6]: rx_phy_ip_err_discards: 0
 [6]: rx_csum_offload_errors: 0
 [7]: rx_phy_ip_err_discards: 0
 [7]: rx_csum_offload_errors: 0
 rx_error_bytes: 0
 rx_crc_errors: 0
 rx_align_errors: 0
 rx_phy_ip_err_discards: 0
 rx_csum_offload_errors: 0
 tx_error_bytes: 0
 tx_mac_errors: 0
 tx_carrier_errors: 0
 tx_deferred: 0
 recoverable_errors: 0
 unrecoverable_errors: 0

Mögliches Problem: Server A hat Tonnen von rx_csum_offload_errors. Server A ist derjenige in der Produktion, und ich kann nicht anders, als zu glauben, dass CPU-Interrupts hier ein zugrunde liegender Faktor sein können und was die Fehler verursacht, die ich sehe.

cat / proc / interrupts von Server A:

122:   54938283          0          0          0          0            0          0          0          0          0          0          0            0          0          0          0          0          0          0           0          0          0          0          0  IR-PCI-MSI-edge      em1-  TxRx-0
123:   51653771          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      em1-TxRx-1
124:   52277181          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      em1-TxRx-2
125:   51823314          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      em1-TxRx-3
126:   57975011          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      em1-TxRx-4
127:   52333500          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      em1-TxRx-5
128:   51899210          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      em1-TxRx-6
129:   61106425          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      em1-TxRx-7
130:   51774758          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      em1-TxRx-8
131:   52476407          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      em1-TxRx-9
132:   53331215          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      em1-TxRx-10
133:   52135886          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0

Würde das Deaktivieren der RX-Prüfsumme helfen, wenn dies das Problem sein könnte? Außerdem sehe ich keine CPU-Interrupts auf dem Server, der nicht in Produktion ist, was sinnvoll ist, da die Netzwerkkarte keine CPU-Zeit benötigt.

Server A:
 ethtool -k em1
Features for em1:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: on
tx-checksum-unneeded: off
tx-checksum-ip-generic: off
tx-checksum-ipv6: on
tx-checksum-fcoe-crc: on [fixed]
tx-checksum-sctp: on [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: off
tx-tcp6-segmentation: on
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: on
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: on [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: on [fixed]
tx-gre-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
fcoe-mtu: off [fixed]
loopback: off [fixed]

Was kann ich außer der Verwendung von Jumbo-Frames, die nicht möglich sind, weil unsere Netzwerkgeräte sie nicht unterstützen, noch tun oder überprüfen, um die bestmögliche TCP-Leistung für mein 10-Gbit-Netzwerk zu erzielen? Die 6,67 Gbit / s sind nicht so schlecht, wenn man bedenkt, dass einer der Server in Produktion ist und meine Hypothese über die CPU-Interrupts, die die Netzwerkkarte generiert. Die Geschwindigkeit von 20 Mbit / s in die andere Richtung auf einer 10-Gbit-Verbindung ist jedoch einfach nicht akzeptabel. Jede Hilfe wäre sehr dankbar.

Server A-Spezifikationen: x64 24 V CPU 32 GB RAM RHEL 6.7

Server B Technische Daten: x64 16v CPU 16GB RAM RHEL 6.7

networking  redhat  tcp  kernel 
— user53029
quelle
Sind die Server mit den gleichen Spezifikationen? Ist irqbalanceaktiviert? Verwenden Sie ein optimiertes Profil ?
— ewwhite
Die Frage wurde aktualisiert, um die technischen Daten aufzunehmen. irqbalance ist nicht aktiviert und kein abgestimmtes Profil.
— user53029
Hier gibt es eine Menge Tuning-Informationen. Ich habe es mehr als ein paar Mal benutzt. schnellerdata.es.net
— Stefan Lasiewski

Antworten:

5

Unter Linux / Intel würde ich die folgende Methode zur Leistungsanalyse verwenden:

Hardware:

  • turbostat
    Suchen Sie nach C / P-Zuständen für Kerne, Frequenzen und Anzahl der SMIs. [1]
  • cpufreq-info
    Suchen Sie nach dem aktuellen Treiber, den Frequenzen und dem Regler.
  • atop
    Suchen Sie nach Interrupt-Verteilung über Kerne.
    Suchen Sie nach Kontextschaltern und Interrupts.
  • ethtool
    -S für Statistiken, nach Fehlern,
    Abbrüchen , Überläufen, verpassten Interrupts usw. suchen -k für Offloads, GRO / GSO aktivieren, rss (/ rps / rfs) / xps
    -g für Ringgrößen,
    -c für Interrupt-Koaleszenz erhöhen

Kernel:

  • /proc/net/softirq[2] und /proc/interrupts[3]
    Wieder Verteilung, verpasste, verzögerte Interrupts, (optional) NUMA-Affinität
  • perf top
    Schauen Sie, wo Kernel / Benchmark seine Zeit verbringt.
  • iptables
    Überprüfen Sie, ob es Regeln gibt (falls vorhanden), die die Leistung beeinträchtigen können.
  • netstat -s, netstat -m, /proc/net/*
    Geben Sie für Fehlerzähler und Puffer zählt
  • sysctl / grub Hier gibt es
    so viel zu optimieren. Versuchen Sie, die Größe der Hashtabellen zu erhöhen, indem Sie mit Speicherpuffern, Überlastungskontrolle und anderen Reglern spielen.

In Ihrem Fall besteht Ihr Hauptproblem in der Interrupt-Verteilung auf die Kerne. Daher ist die Behebung dieses Problems die beste Lösung.

PS. Vergessen Sie nicht, dass bei solchen Benchmarks Kernel- und Treiber- / Firmware-Versionen eine wichtige Rolle spielen.

PPS. Sie möchten wahrscheinlich den neuesten ixgbeTreiber von Intel [4] installieren . Vergessen Sie nicht, dort README zu lesen und das Skriptverzeichnis zu überprüfen. Es hat viele leistungsbezogene Tipps.

[0] Intel hat auch nette Dokumente zur Skalierung der Netzwerkleistung
https://www.kernel.org/doc/Documentation/networking/scaling.txt
[1] Sie können Ihren Prozessor einem bestimmten C-Status
zuordnen: https: // gist.github.com/SaveTheRbtz/f5e8d1ca7b55b6a7897b
[2] Sie können diese Daten analysieren mit:
https://gist.github.com/SaveTheRbtz/172b2e2eb3cbd96b598d
[3] Sie können die Affinität festlegen zu:
https://gist.github.com / SaveTheRbtz / 8875474
[4] https://sourceforge.net/projects/e1000/files/ixgbe%20stable/

— SaveTheRbtz
quelle
3

Haben die Server die gleichen Spezifikationen (Marke und Modell)? Haben Sie Änderungen an der sysctl.conf vorgenommen?

Sie sollten irqbalance aktivieren, da Ihre Interrupts nur auf CPU0 auftreten.

Wenn Sie mit EL6 kein optimiertes Profil verwenden, sollten Sie ein Profil auswählen, das Ihrer Arbeitslast gemäß dem hier angegebenen Zeitplan entspricht .

— ewwhite
quelle
Nein, Server A ist ein Dell PE R620 mit einer Intel Corporation 82599ES 10-Gigabit-SFI / SFP + -Netzwerkverbindung (Version 01) und Server B ein Dell PE 430 mit Broadcom Corporation NetXtreme II BCM57810 10 Gigabit Ethernet (Version 10). Gibt es Best Practices für die Optimierung des Ungleichgewichts für 10-Gbit-Ethernet oder starte ich einfach den Dienst und das wars? Ich habe mit sysctl keine Änderung vorgenommen.
— user53029
1
Starten Sie einfach den Dienst.
— ewwhite
1

Eine Geschwindigkeit von 6 Gbit / s ist in Ordnung, wenn Sie nur eine Instanz von iperf ausführen, da diese auf einen einzelnen CPU-Kern beschränkt ist. Zwei Prozesse gleichzeitig sollten Ihnen erwartete 10 Gbit / s ergeben.

Das Problem mit 20 MBit / s in eine Richtung scheint ein Problem mit der Inkompatibilität von Treiber, Firmware und Hardware zu sein.

Ich empfehle Ihnen, die folgenden Schritte zur Fehlerbehebung auszuführen:

Ihre Netzwerkkarten verfügen über zwei Ports. Versuchen Sie daher zunächst, Loopback-Geschwindigkeitstests auf beiden Netzwerkkarten durchzuführen. Es kann Ihnen helfen, das Problem zu lokalisieren: auf Server A oder auf Server B. 2. Wechseln Sie die Patchkabel. 3. Probieren Sie neue Treiber aus. 4. Aktualisieren Sie die Firmware. 5. NICs ändern)

— angst
quelle
Wenn ich 2 parallele Streams laufen lasse, habe ich ungefähr 9 Gbit / s. Mir ist auch aufgefallen, dass ich bei parallelen Streams in langsamer Richtung, beispielsweise bis zu 10, ungefähr 220 MBit / s erreichen kann. 100 parallel und ich bekomme 1,8 Gb / s. Es scheint also die Fähigkeit zu haben, mehr Daten herauszuschieben, und theoretisch könnte ich, wenn ich genügend Streams verwenden würde, wahrscheinlich das Maximum der Schaltung erreichen. Aber warum braucht es nur 2 Streams in eine Richtung und mehrere in die andere?
— user53029
Langsame Richtung ist immer von Server A zu Server B?
— Angst
Ja, wenn Server A der iperf-Client ist und Server B die Pakete akzeptiert.
— user53029
Versuchen Sie es mit einem anderen optischen Patch. Oder tauschen Sie die Fasern der jetzt verwendeten aus. Vielleicht ist es kaputt.
— ängstlich
1

Ich würde versuchen, LRO (Large Receive Offload) zu deaktivieren ... Ich würde vermuten, dass Sie eine mit eingeschaltetem und eine mit ausgeschaltetem Gerät haben.

Es ist NIC / fahrerabhängig, aber im Allgemeinen wissen wir, wenn wir das in unserer Umgebung sehen, dass wir eine verpasst haben, und deaktivieren LRO

— Kettlewell
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.