web-dev-qa-db-ja.com

TCPたくさんの接続と小さなパケットの高いトラフィックを持つギガビットネットワーク上のパフォーマンスを改善する

TCP「接続数が多く、小さなパケットのトラフィックが多いギガビットネットワーク」でのスループットを改善しようとしています。私のサーバーOSはUbuntu 11.10サーバー64ビットです。

TCPソケット（すべて同じポート上））を介してサーバーに接続されている約50.000の（そして増え続ける）クライアントがあります。

パケットの95％のサイズは1〜150バイト（TCPヘッダーとペイロード）です。残りの5％は150から4096+バイトまで変化します。

以下の設定で、私のサーバーは最大30 Mbps（全二重）のトラフィックを処理できます。

私のニーズに合わせてOSを調整するためのベストプラクティスをアドバイスしていただけますか？

俺の /etc/sysctl.congは次のようになります。

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

これが私の限界です：

$ 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

[追加]

私のNICは次のとおりです。

$ 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

[追加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

[追加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

SACKに関する情報： TCP SACKをオフにするタイミング

linuxubuntunetworkingkernelsysctl
37
Worker

問題は、ネットワークカードの割り込みが多すぎることである可能性があります。帯域幅に問題がない場合は、周波数に問題があります。

  • ネットワークカードの送信/受信バッファを上げる

    ethtool -g eth0

現在の設定（256または512エントリ）が表示されます。おそらくこれらを1024、2048、または3172に上げることができます。これ以上はおそらく意味がありません。これは、サーバーが着信パケットを十分な速度で処理できない場合にのみ一杯になるリングバッファです。

バッファーがいっぱいになり始めた場合、フロー制御はルーターまたはスイッチにスローダウンを指示する追加の手段です。

  • サーバーと、サーバーが接続されているスイッチ/ルーターポートで、フロー制御イン/アウトバウンドをオンにします。

    ethtool -a eth0

おそらく表示されます：

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

/ var/log/messagesでeth0の現在の設定を確認します。次のようなものを確認してください：

eth0：リンクは1000 Mbps、全二重、フロー制御txおよびrxでアップしています

Txとrxが表示されない場合は、ネットワーク管理者がスイッチ/ルーターの値を調整する必要があります。受信/送信フロー制御がオンになっているシスコ。

注意：これらの値を変更すると、リンクが非常に短時間（1秒未満）ダウンまたはアップします。

  • これでも問題が解決しない場合は、ネットワークカードの速度を100 MBitに下げることもできます（スイッチ/ルーターポートでも同じことを行います）。

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

しかし、あなたの場合、私は言うでしょう-NICリングバッファで受信バッファを上げます。

21
Nils

以下は決定的な答えではないかもしれませんが、それは間違いなくいくつかのアイデアを出します

これらをsysctl.confに追加してみてください

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

選択的なtcp ackは、高帯域幅ネットワークの場合に最適なパフォーマンスを得るのに適しています。ただし、他の 欠点 には注意してください。ウィンドウスケーリングの利点について説明します here 。 3番目のsysctlオプションについて：デフォルトでは、TCPは接続が閉じたときにさまざまな接続メトリックをルートキャッシュに保存するため、近い将来確立される接続はこれらを使用して初期条件を設定できます。通常、これにより、全体的なパフォーマンスは向上しますが、パフォーマンスが低下することがあります。設定すると、TCPは接続を閉じるときにメトリックをキャッシュしません。

確認する

ethtool -k ethX

オフロードが有効になっているかどうかを確認します。 TCPチェックサムオフロード および大規模セグメントオフロードは、今日の大部分のイーサネットNICでサポートされており、明らかに Broadcom でもサポートされています。

ツールを使用してみてください

powertop

ネットワークがアイドル状態で、ネットワークが飽和状態に達したとき。 NIC=割り込みが原因である場合、これは間違いなく表示されます。デバイスのポーリングがそのような状況への答えです。FreeBsdはifconfig内でポーリングスイッチをサポートしていますが、Linuxにはそのようなオプションがありません。相談してください this ポーリングを有効にするBroadComはポーリングもサポートしていると言っています。

ジャンボパケットの微調整 は、トラフィックの大部分が小さなパケットで構成されていると説明したため、カットされない場合があります。しかし、とにかくそれを試してみてください！

5
kaji

私の場合、単一の調整のみ：

net.ipv4.tcp_timestamps = 0

サイトの読み込み時間を50％短縮した、非常に大きな便利な変更を行いました。

2
avz2012

私はこれを提案します：

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

RHELのOracle DBサーバーおよびバックアップソフトウェアでテスト済み。

2
Konrad Puchała

微調整のリストでタイムスタンプがオフになっていることに気づきました。それを行わないでください。これは、帯域幅が非常に高価で、人々が数バイト/パケットを節約したいと思っていた昔の時代にさかのぼります。たとえば、最近ではTCPスタックで使用され、「CLOSE_WAIT」のソケットに到着するパケットが接続の古いパケットであるか、それとも新しいパケットであるかを判断するために使用されます。新しい接続とRTT計算に役立ちます。また、タイムスタンプの数バイトを節約することは、IPv6アドレスが追加するものと比較して何もありません。タイムスタンプをオフにすることは、害よりも害が大きくなります。

タイムスタンプをオフにするためのこの推奨事項は、ある世代のsysadminから次の世代に渡されることになる単なる逆戻りです。一種の「都市伝説」のようなもの。

2
GeorgeB

すべてのCPUコアに負荷を分散する必要があります。 'irqbalance'を起動します。

2
user175978