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
quelle
irqbalanceaktiviert? Verwenden Sie ein optimiertes Profil ?Antworten:
Unter Linux / Intel würde ich die folgende Methode zur Leistungsanalyse verwenden:
Hardware:
turbostatSuchen Sie nach C / P-Zuständen für Kerne, Frequenzen und Anzahl der SMIs. [1]
cpufreq-infoSuchen Sie nach dem aktuellen Treiber, den Frequenzen und dem Regler.
atopSuchen 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 topSchauen 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
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/
quelle
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 .
quelle
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)
quelle
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
quelle