Frage Verbesserung der TCP-Leistung über ein Gigabit-Netzwerk mit vielen Verbindungen und hohem Datenverkehr mit kleinen Paketen


Ich versuche, meinen TCP-Durchsatz über ein "Gigabit-Netzwerk mit vielen Verbindungen und hohem Verkehr von kleinen Paketen" zu verbessern. Mein Server OS ist Ubuntu 11.10 Server 64bit.

Es gibt ungefähr 50.000 (und wachsende) Clients, die über TCP-Sockets (alle am selben Port) mit meinem Server verbunden sind.

95% meiner Pakete haben eine Größe von 1-150 Bytes (TCP-Header und Payload). Die restlichen 5% variieren von 150 bis zu 4096 Bytes.

Mit der unten stehenden Konfiguration kann mein Server Verkehr mit bis zu 30 Mbit / s (Vollduplex) verarbeiten.

Können Sie mir bitte Best Practice empfehlen, um OS auf meine Bedürfnisse abzustimmen?

Meine /etc/sysctl.cong sieht aus wie das:

kernel.pid_max = 1000000
net.ipv4.ip_local_port_range = 2500 65000
fs.file-max = 1000000
#
net.core.netdev_max_backlog=3000
net.ipv4.tcp_sack=0
#
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.somaxconn = 2048
#
net.ipv4.tcp_rmem = 4096 87380 16777216 
net.ipv4.tcp_wmem = 4096 65536 16777216
#
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_mem = 50576   64768   98152
#
net.core.wmem_default = 65536
net.core.rmem_default = 65536
net.ipv4.tcp_window_scaling=1
#
net.ipv4.tcp_mem= 98304 131072 196608
#
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_rfc1337 = 1
net.ipv4.ip_forward = 0
net.ipv4.tcp_congestion_control=cubic
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 0
#
net.ipv4.tcp_orphan_retries = 1
net.ipv4.tcp_fin_timeout = 25
net.ipv4.tcp_max_orphans = 8192

Hier sind meine Grenzen:

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 193045
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1000000
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1000000

[HINZUGEFÜGT]

Meine Netzwerkkarten sind die folgenden:

$ dmesg | grep Broad
[    2.473081] Broadcom NetXtreme II 5771x 10Gigabit Ethernet Driver bnx2x 1.62.12-0 (2011/03/20)
[    2.477808] bnx2x 0000:02:00.0: eth0: Broadcom NetXtreme II BCM57711E XGb (A0) PCI-E x4 5GHz (Gen2) found at mem fb000000, IRQ 28, node addr d8:d3:85:bd:23:08
[    2.482556] bnx2x 0000:02:00.1: eth1: Broadcom NetXtreme II BCM57711E XGb (A0) PCI-E x4 5GHz (Gen2) found at mem fa000000, IRQ 40, node addr d8:d3:85:bd:23:0c

[HINZUGEFÜGT 2]

ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
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: off

[HINZUGEFÜGT 3]

 sudo ethtool -S eth0|grep -vw 0
 NIC statistics:
      [1]: rx_bytes: 17521104292
      [1]: rx_ucast_packets: 118326392
      [1]: tx_bytes: 35351475694
      [1]: tx_ucast_packets: 191723897
      [2]: rx_bytes: 16569945203
      [2]: rx_ucast_packets: 114055437
      [2]: tx_bytes: 36748975961
      [2]: tx_ucast_packets: 194800859
      [3]: rx_bytes: 16222309010
      [3]: rx_ucast_packets: 109397802
      [3]: tx_bytes: 36034786682
      [3]: tx_ucast_packets: 198238209
      [4]: rx_bytes: 14884911384
      [4]: rx_ucast_packets: 104081414
      [4]: rx_discards: 5828
      [4]: rx_csum_offload_errors: 1
      [4]: tx_bytes: 35663361789
      [4]: tx_ucast_packets: 194024824
      [5]: rx_bytes: 16465075461
      [5]: rx_ucast_packets: 110637200
      [5]: tx_bytes: 43720432434
      [5]: tx_ucast_packets: 202041894
      [6]: rx_bytes: 16788706505
      [6]: rx_ucast_packets: 113123182
      [6]: tx_bytes: 38443961940
      [6]: tx_ucast_packets: 202415075
      [7]: rx_bytes: 16287423304
      [7]: rx_ucast_packets: 110369475
      [7]: rx_csum_offload_errors: 1
      [7]: tx_bytes: 35104168638
      [7]: tx_ucast_packets: 184905201
      [8]: rx_bytes: 12689721791
      [8]: rx_ucast_packets: 87616037
      [8]: rx_discards: 2638
      [8]: tx_bytes: 36133395431
      [8]: tx_ucast_packets: 196547264
      [9]: rx_bytes: 15007548011
      [9]: rx_ucast_packets: 98183525
      [9]: rx_csum_offload_errors: 1
      [9]: tx_bytes: 34871314517
      [9]: tx_ucast_packets: 188532637
      [9]: tx_mcast_packets: 12
      [10]: rx_bytes: 12112044826
      [10]: rx_ucast_packets: 84335465
      [10]: rx_discards: 2494
      [10]: tx_bytes: 36562151913
      [10]: tx_ucast_packets: 195658548
      [11]: rx_bytes: 12873153712
      [11]: rx_ucast_packets: 89305791
      [11]: rx_discards: 2990
      [11]: tx_bytes: 36348541675
      [11]: tx_ucast_packets: 194155226
      [12]: rx_bytes: 12768100958
      [12]: rx_ucast_packets: 89350917
      [12]: rx_discards: 2667
      [12]: tx_bytes: 35730240389
      [12]: tx_ucast_packets: 192254480
      [13]: rx_bytes: 14533227468
      [13]: rx_ucast_packets: 98139795
      [13]: tx_bytes: 35954232494
      [13]: tx_ucast_packets: 194573612
      [13]: tx_bcast_packets: 2
      [14]: rx_bytes: 13258647069
      [14]: rx_ucast_packets: 92856762
      [14]: rx_discards: 3509
      [14]: rx_csum_offload_errors: 1
      [14]: tx_bytes: 35663586641
      [14]: tx_ucast_packets: 189661305
      rx_bytes: 226125043936
      rx_ucast_packets: 1536428109
      rx_bcast_packets: 351
      rx_discards: 20126
      rx_filtered_packets: 8694
      rx_csum_offload_errors: 11
      tx_bytes: 548442367057
      tx_ucast_packets: 2915571846
      tx_mcast_packets: 12
      tx_bcast_packets: 2
      tx_64_byte_packets: 35417154
      tx_65_to_127_byte_packets: 2006984660
      tx_128_to_255_byte_packets: 373733514
      tx_256_to_511_byte_packets: 378121090
      tx_512_to_1023_byte_packets: 77643490
      tx_1024_to_1522_byte_packets: 43669214
      tx_pause_frames: 228

Einige Informationen über SACK: Wann TCP SACK ausschalten?


36
2018-02-07 22:10


Ursprung


Dies kann helfen: datatag.web.cern.ch/datatag/howto/tcp.html - yarek
Was ist der begrenzende Faktor? Hat Ihre CPU maximale Leistung? Wenn das so ist, bellst du den falschen Baum an. Sie müssen sehen, was die CPU macht. - David Schwartz
Welche NIC hast du? - SaveTheRbtz
BTW: Warum schalten Sie SACK aus? - Nils
Sie sollten die Verwendung von Broadcom NICs überdenken ... - Hubert Kario


Antworten:


Das Problem besteht möglicherweise darin, dass auf Ihrer Netzwerkkarte zu viele Unterbrechungen auftreten. Wenn Bandbreite nicht das Problem ist, ist die Häufigkeit das Problem:

  • Schalten Sie Sende- / Empfangspuffer auf der Netzwerkkarte ein

    ethtool -g eth0
    

Zeigt Ihnen die aktuellen Einstellungen (256 oder 512 Einträge). Sie können diese wahrscheinlich auf 1024, 2048 oder 3172 erhöhen. Mehr macht wahrscheinlich keinen Sinn. Dies ist nur ein Ringpuffer, der nur dann voll wird, wenn der Server eingehende Pakete nicht schnell genug verarbeiten kann.

Wenn der Puffer zu füllen beginnt, ist die Flusskontrolle ein zusätzliches Mittel, um den Router oder Switch zu verlangsamen:

  • Aktivieren Sie die Flusskontrolle auf dem Server und den Switch / Router-Ports, mit denen er verbunden ist.

    ethtool -a eth0
    

Wird wahrscheinlich zeigen:

Pause parameters for eth0:
Autonegotiate:  on
RX:             on
TX:             on

Überprüfen Sie / var / log / messages für die aktuelle Einstellung von eth0. Suchen Sie nach etwas wie:

eth0: Die Verbindung besteht bei 1000 Mbit / s, Vollduplex, Flusssteuerung tx und rx

Wenn Sie tx und rx nicht sehen, müssen Ihre Netzwerkadministratoren die Werte auf dem Switch / Router anpassen. Bei Cisco, das die Flusskontrolle empfängt / überträgt.

In acht nehmen: Wenn Sie diese Werte ändern, wird Ihre Verbindung für eine sehr kurze Zeit (weniger als 1s) heruntergefahren.

  • Wenn das alles nicht hilft - können Sie auch die Geschwindigkeit der Netzwerkkarte auf 100 MBit senken (tun Sie das gleiche an den Switch / Router-Ports)

    ethtool -s eth0 autoneg off && ethtool -s eth0 speed 100
    

Aber in Ihrem Fall würde ich sagen: Heben Sie die Empfangspuffer im NIC-Ringpuffer auf.


20
2018-02-11 22:45



Betrachte deine Zahlen von ethtool Ich würde sagen - setzen Sie die Empfangspuffer der Netzwerkkarte auf das Maximum, um die RX-Rückwürfe zu vermeiden. Ich hoffe, Ihr Broadcom hat genug davon. - Nils
Zunehmende Pufferung mit TCP ist fast nie eine gute Idee. Wir haben schon viel zu viel Pufferung: bufferbloat.net/projects/bloat/wiki/Einleitung - rmalayter
Dieser Puffer ist ein Hardwarepuffer direkt auf der Netzwerkkarte. Ich werde meine Antwort mit weiteren Details aktualisieren. Da Sie eingehende Pakete verlieren, benötigen Sie diesen Puffer. Ich habe einen ähnlichen Server, wo ich zu einem anderen NIC (von onboard Broadcom zu PCIe Intel) wechseln musste, um diese Puffer zu erhöhen. Danach habe ich keine verlorenen RX-Pakete mehr gesehen. - Nils
@malayter: Dies ist ein Ring-Puffer auf Schicht 2. Siehe meine aktualisierte Antwort. - Nils
Endlich haben wir 1GB. Es gab viel Tuning an verschiedenen Orten, also kann ich nicht wirklich sagen, dass es ein einziges Problem gab. - Worker


Das Folgende ist vielleicht nicht die definitive Antwort, aber es wird definitiv einige Ideen hervorbringen

Versuchen Sie, diese zu sysctl.conf hinzuzufügen

##  tcp selective acknowledgements. 
net.ipv4.tcp_sack = 1
##enable window scaling
net.ipv4.tcp_window_scaling = 1
##
net.ipv4.tcp_no_metrics_save = 1

Während selektive TCP-Ack für eine optimale Leistung im Fall von Netzwerk mit hoher Bandbreite gut ist. Aber hüte dich vor anderen Nachteile obwohl. Die Vorteile der Fensterskalierung werden beschrieben Hier. Wie für dritte sysctl Option: Standardmäßig speichert TCP beim Schließen der Verbindung verschiedene Verbindungsmetriken im Routencache, so dass in naher Zukunft aufgebaute Verbindungen diese zum Festlegen von Anfangsbedingungen verwenden können. Normalerweise erhöht dies die Gesamtleistung, kann jedoch manchmal zu Leistungseinbußen führen. Wenn diese Option festgelegt ist, speichert TCP beim Schließen von Verbindungen keine Metriken.

Überprüfen mit

ethtool -k ethX

um zu sehen, ob das Ausladen aktiviert ist oder nicht. TCP-Prüfsummen-Offload und große Segment Offload werden von der Mehrheit der heutigen Ethernet-NICs und anscheinend unterstützt Broadcom unterstützt es auch.

Versuchen Sie es mit dem Werkzeug

powertop

während das Netzwerk im Leerlauf ist und wenn die Netzwerk-Sättigung erreicht ist. Dies wird definitiv zeigen, wenn NIC-Interrupts der Schuldige sind. Geräteabfragen sind eine Antwort auf solche Situationen. FreeBsd unterstützt Polling-Schalter direkt in ifconfig, aber Linux hat keine solche Option. Konsultieren diese Umfragen zu ermöglichen. BroadCom unterstützt auch die Umfrage, was eine gute Nachricht für Sie ist.

Jumbo-Paket optimieren Vielleicht schneiden Sie es nicht für Sie ab, da Sie erwähnt haben, dass Ihr Traffic hauptsächlich aus kleinen Paketen besteht. Aber hey probier es trotzdem aus!


4
2018-02-12 05:22



2kaji, ich werde dir morgen Vorschläge vorschlagen. Über PowerTop - Sollte ich das Energiesparen optimieren, wenn mein Ziel die Leistung ist? - Worker
Ja, das könnte natürlich auch helfen. Ich habe Powertop erwähnt, nur um sicher zu gehen, ob Interrupts das Böse sind. Interrupts Häufigkeit könnte auch von anderen Tools geerntet werden - kaji
Ich sehe hohe "Umplanungsunterbrechungen" - könnte das ein Grund sein? Was ist "Umplanungsinterrupts"? - Worker
Versuchen Sie, dem zu folgen ---> help.ubuntu.com/community/ResminingInterrupts - kaji
yeah .. Ich habe dieses Tutorial gesehen, aber es ist für Laptops, während ich hohe Unterbrechungen im Server sehe. Wird versuchen, es auf den Server anzuwenden. - Worker


Sie müssen die Last auf alle CPU-Kerne verteilen. Starten Sie 'irqbalance'.


1
2018-05-31 01:54



Dies hilft nicht, wenn ein einzelner IRQ eine sehr hohe Frequenz hat. IRQBalance versucht, einzelne IRQs an logische Prozessoren zu verteilen - aber es gibt nie mehr als einen Prozessor, der einen einzelnen IRQ bedient. - Nils


Ich schlage das vor:

kernel.sem = 350 358400 64 1024
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 4194304
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_adv_win_scale = 2
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_rmem = 4096 262144 4194304
net.ipv4.tcp_wmem = 4096 262144 4194304
net.ipv4.tcp_keepalive_time = 900
net.ipv4.tcp_keepalive_intvl = 900
net.ipv4.tcp_keepalive_probes = 9

Getestet in Oracle DB-Servern auf RHEL und in Backup-Software.


1
2018-02-19 11:15



Diese Nummern sind konfigurierbar, da es keine Einheitsgröße gibt. Das bedeutet, dass die Zahlen selbst nicht wertvoll sind. Was könnte wertvoll sein, ist die Methode, die Sie verwendet haben, um zu entscheiden, welche Zahlen verwendet werden sollen. - kasperd


In meinem Fall nur ein einziges Tuning:

net.ipv4.tcp_timestamps = 0

eine sehr große und nützliche Änderung vorgenommen, Ladezeit der Website um 50% reduziert.


1
2018-02-19 10:57



Etwas muss in deinem Setup stark beschädigt sein, damit dies geschieht. Zeitstempel verwenden unter normalen Umständen weniger als 1% der Bandbreite und ermöglichen es TCP, Wiederholungsübertragungen sehr viel zeitnäher als sonst durchzuführen. - kasperd


Ich habe festgestellt, dass Timestamps in der Liste der Tweaks deaktiviert sind, bitte tu das nicht. Das ist ein alter Rückgriff auf frühere Zeiten, als die Bandbreite wirklich teuer war und die Leute ein paar Bytes / Paket speichern wollten. Es wird heutzutage beispielsweise vom TCP-Stack verwendet, um festzustellen, ob ein Paket, das für einen Socket in "CLOSE_WAIT" ankommt, ein altes Paket für die Verbindung oder ein neues Paket für eine neue Verbindung ist und bei RTT-Berechnungen hilft. Und das Speichern der wenigen Bytes für einen Zeitstempel ist NOTHING im Vergleich zu dem, was IPv6-Adressen hinzufügen werden. Das Ausschalten von Zeitstempeln schadet mehr als nützt.

Diese Empfehlung zum Ausschalten von Zeitstempeln ist nur ein Rückfall, der von Generation zu Generation weitergegeben wird. Eine Art "städtische Legende".


0
2018-05-13 16:39