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

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

Es gibt ungefähr 50.000 (und immer mehr) 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 folgenden Konfiguration kann mein Server Datenverkehr mit bis zu 30 Mbit / s (Vollduplex) verarbeiten.

Können Sie mir bitte die beste Vorgehensweise zur Anpassung des Betriebssystems an meine Bedürfnisse empfehlen?

Mein /etc/sysctl.congsieht so aus:

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 lauten wie folgt:

$ 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

[ADDED 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 zu SACK: Wann sollte TCP SACK ausgeschaltet werden?

Das Problem könnte sein, dass Ihre Netzwerkkarte zu viele Interrupts enthält. Wenn die Bandbreite nicht das Problem ist, ist die Frequenz das Problem:

• Erhöhen Sie die Sende- / Empfangspuffer auf der Netzwerkkarte

  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 ergibt wahrscheinlich keinen Sinn. Dies ist nur ein Ringpuffer, der sich nur füllt, wenn der Server eingehende Pakete nicht schnell genug verarbeiten kann.

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

• Schalten Sie die Flusskontrolle auf dem Server und den damit verbundenen Switch- / Router-Ports ein und aus.

  ethtool -a eth0
  

Wird wahrscheinlich zeigen:

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

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

eth0: Die Verbindung ist bei 1000 Mbit / s, Vollduplex, Flusskontrolle, TX und RX aktiv

Wenn Sie tx und rx nicht sehen, müssen Ihre Netzwerkadministratoren die Werte auf dem Switch / Router anpassen. Bei Cisco ist die Empfangs- / Sendeflusskontrolle eingeschaltet.

Achtung: Wenn Sie diese Werte ändern, wird Ihre Verbindung für eine sehr kurze Zeit (weniger als 1 Sekunde) unterbrochen und wiederhergestellt.

• Wenn all dies nicht hilft, können Sie auch die Geschwindigkeit der Netzwerkkarte auf 100 MBit verringern (machen Sie dasselbe auf den Switch / Router-Ports).

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

Aber in Ihrem Fall würde ich sagen - erhöhen Sie die Empfangspuffer im NIC-Ringpuffer.

Es mag sein, dass das Folgende nicht die endgültige Antwort ist, 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-Bestätigung für eine optimale Leistung im Falle eines Netzwerks mit hoher Bandbreite gut ist. Aber hüten Sie sich vor anderen Nachteilen . Die Vorteile der Fensterskalierung werden hier beschrieben . Zur dritten sysctl-Option: Standardmäßig speichert TCP verschiedene Verbindungsmetriken im Routen-Cache, wenn die Verbindung geschlossen wird, damit in naher Zukunft hergestellte Verbindungen diese zum Festlegen der 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 keine Metriken beim Schließen von Verbindungen.

Überprüfen Sie mit

ethtool -k ethX

um zu sehen, ob das Auslagern aktiviert ist oder nicht. TCP Checksum Offload und Large Segment Offload werden von der Mehrzahl der heutigen Ethernet-NICs unterstützt und anscheinend auch von Broadcom .

Versuchen Sie es mit dem Werkzeug

powertop

Während das Netzwerk inaktiv ist und wenn die Netzwerksättigung erreicht ist. Dies wird auf jeden Fall zeigen, ob NIC-Interrupts der Schuldige sind. Device Polling ist eine Antwort auf eine solche Situation. FreeBsd unterstützt Polling-Schalter direkt in ifconfig, aber Linux hat keine solche Option. Wenden Sie sich an diese Option , um die Abfrage zu aktivieren. Es heißt, dass BroadCom auch Umfragen unterstützt, was für Sie eine gute Nachricht ist.

Jumbo Packet Tweak ist möglicherweise nicht für Sie geeignet, da Sie erwähnt haben, dass der Datenverkehr hauptsächlich aus kleinen Paketen besteht. Aber probieren Sie es trotzdem aus!

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

Ich habe in der Liste der Optimierungen festgestellt, dass die Zeitstempel deaktiviert sind. Tun Sie das bitte nicht. Das ist ein alter Rückfall zu früheren Zeiten, als Bandbreite sehr teuer war und die Leute ein paar Bytes / Paket sparen wollten. Es wird beispielsweise heutzutage 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 ist oder ob es ein neues Paket für eine neue Verbindung ist und bei RTT-Berechnungen hilft. Das Speichern der wenigen Bytes für einen Zeitstempel ist NICHTS im Vergleich zu den IPv6-Adressen, die hinzugefügt werden. Zeitstempel auszuschalten schadet mehr als es nützt.

Diese Empfehlung zum Deaktivieren von Zeitstempeln ist nur ein Rückschritt, der von einer Sysadmin-Generation zur nächsten weitergegeben wird. So etwas wie eine "urbane Legende".

Ich schlage 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.

In meinem Fall nur ein einziges Tuning:

net.ipv4.tcp_timestamps = 0

Es wurde eine sehr große und nützliche Änderung vorgenommen. Die Ladezeit der Website wurde um 50% verringert.