大規模なRTTで1GbpsサーバーからのTCPスループットが100Mbpsサーバーよりも低い

インフラストラクチャは、シンガポール、ロンドン、ロサンゼルスなど、世界中のいくつかの主要な場所に分散しています。2つの場所間のRTTは150ms以上です。

最近、すべてのサーバーを1Gbpsリンクを使用するようにアップグレードしました（100Mbpsから）。私たちはさまざまな場所にあるサーバー間でいくつかのTCPベースのテストを実行しており、いくつかの驚くべき結果を見てきました。これらの結果は完全に再現可能です。

1. ロサンゼルス（100Mbps）からロンドン（100Mbps）：〜96Mbpsスループット
2. ロサンゼルス（100Mbps）からロンドン（1Gbps）：〜96Mbpsスループット
3. ロサンゼルス（1Gbps）からロンドン（100Mbps）：10-40Mbpsスループット（揮発性）
4. ロサンゼルス（1Gbps）からロンドン（1Gbps）：10-40Mbpsスループット（揮発性）
5. ロサンゼルス（1Gbps）からロサンゼルス（1Gbps）：900Mbpsを超えるスループット

送信側が1Gbpsで実行されている場合は常に、長いリンクではスループットが大幅に低下するようです。

以前のテストアプローチは非常に単純です-私はcURLを使用してターゲットサーバーから1GBのバイナリをダウンロードしています（上記の場合、cURLクライアントはロンドンのサーバーで実行され、LAからダウンロードするため、LAが送信者になります）。 。もちろん、これは単一のTCP接続を使用しています。

iperfを使用してUDPで同じテストを繰り返すと、問題が解消します。

1. ロサンゼルス（100Mbps）からロンドン（100Mbps）：〜96Mbpsスループット
2. ロサンゼルス（100Mbps）からロンドン（1Gbps）：〜96Mbpsスループット
3. ロサンゼルス（1Gbps）からロンドン（100Mbps）：〜96Mbpsスループット
4. ロサンゼルス（1Gbps）からロンドン（1Gbps）：250Mbpsを超えるスループット

これは、私の目にあるTCPまたはNIC /ポート構成の問題を直視しています。

両方のサーバーは、TCPキュービックでCentOS 6.xを実行しています。どちらも最大8MBのTCP送受信ウィンドウがあり、TCPタイムスタンプと選択的確認応答が有効になっています。すべてのテストケースで同じTCP構成が使用されます。完全なTCP構成は以下のとおりです。

net.core.somaxconn = 128
net.core.xfrm_aevent_etime = 10
net.core.xfrm_aevent_rseqth = 2
net.core.xfrm_larval_drop = 1
net.core.xfrm_acq_expires = 30
net.core.wmem_max = 8388608
net.core.rmem_max = 8388608
net.core.wmem_default = 131072
net.core.rmem_default = 131072
net.core.dev_weight = 64
net.core.netdev_max_backlog = 1000
net.core.message_cost = 5
net.core.message_burst = 10
net.core.optmem_max = 20480
net.core.rps_sock_flow_entries = 0
net.core.netdev_budget = 300
net.core.warnings = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_retrans_collapse = 1
net.ipv4.tcp_syn_retries = 5
net.ipv4.tcp_synack_retries = 5
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_tw_buckets = 262144
net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_retries1 = 3
net.ipv4.tcp_retries2 = 15
net.ipv4.tcp_fin_timeout = 60
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_abort_on_overflow = 0
net.ipv4.tcp_stdurg = 0
net.ipv4.tcp_rfc1337 = 0
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_orphan_retries = 0
net.ipv4.tcp_fack = 1
net.ipv4.tcp_reordering = 3
net.ipv4.tcp_ecn = 2
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_mem = 1528512      2038016 3057024
net.ipv4.tcp_wmem = 4096        131072  8388608
net.ipv4.tcp_rmem = 4096        131072  8388608
net.ipv4.tcp_app_win = 31
net.ipv4.tcp_adv_win_scale = 2
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_frto = 2
net.ipv4.tcp_frto_response = 0
net.ipv4.tcp_low_latency = 0
net.ipv4.tcp_no_metrics_save = 0
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_tso_win_divisor = 3
net.ipv4.tcp_congestion_control = cubic
net.ipv4.tcp_abc = 0
net.ipv4.tcp_mtu_probing = 0
net.ipv4.tcp_base_mss = 512
net.ipv4.tcp_workaround_signed_windows = 0
net.ipv4.tcp_dma_copybreak = 4096
net.ipv4.tcp_slow_start_after_idle = 1
net.ipv4.tcp_available_congestion_control = cubic reno
net.ipv4.tcp_allowed_congestion_control = cubic reno
net.ipv4.tcp_max_ssthresh = 0
net.ipv4.tcp_thin_linear_timeouts = 0
net.ipv4.tcp_thin_dupack = 0

添付されているのは、いくつかのテストケースのWireshark IOグラフの画像です（申し訳ありませんが、まだ画像を直接投稿することはできません）。

テストケース1（100Mbps-> 100Mbps） -スムーズな転送。捕獲による損失はありません。- http://103.imagebam.com/download/dyNftIGh-1iCFbjfMFvBQw/25498/254976014/100m.png

テストケース3（ 1Gbps- > 100Mbps） -不安定な転送、速度に達するまでに長い時間がかかる-100Mbpsに近づくことはありません。しかし、キャプチャでの損失/再送信はありません！- http://101.imagebam.com/download/KMYXHrLmN6l0Z4KbUYEZnA/25498/254976007/1g.png

つまり、要約すると、1Gbps接続で長いリンクを使用すると、100Mbps接続を使用する場合よりもはるかに低いTCPスループットが得られます。

私はそこにいるTCPエキスパートからのいくつかのポインタに非常に感謝します！

ありがとう！

更新（2013-05-29）：

上記のテストケース＃4で問題を解決しました（1 Gbpsの送信側、1 Gbpsの受信側、大規模なRTT）。これで、転送の開始から数秒以内に970Mbpsに達することができます。問題が表示されますホスティングプロバイダで使用されるスイッチであったと。別のものに移動することで解決しました。

ただし、テストケース＃3はほとんど問題が残ります。100Mbpsで実行しているレシーバーと1Gbpsで送信しているレシーバーがある場合、レシーバーが100Mbpsに到達するまで約2〜3分待機します（ただし、以前とは異なり、フルレートに到達します）。送信側を100 Mbpsに落とすか、受信側を1 Gbpsに上げるとすぐに問題がなくなり、1秒または2秒でフルスピードにランプアップできます。

根本的な理由は、もちろん、転送が開始されて間もなく、損失が発生していることです。ただし、これはスロースタートがどのように機能するかについての私の理解とは一致しません。インターフェースの速度は、レシーバーからのACKによって制御される必要があるため、これには関係ありません。

どうぞよろしくお願いします！ここで賞金を提供できるとしたら、私はそうします！

主な問題は、大きなWAN遅延です。ランダムパケットが失われると、さらに悪化します。

1、より多くのメモリを割り当てるには、tcp_memも大きく設定する必要があります。たとえば、net.ipv4.tcp_mem = 4643328 6191104 9286656と設定します。

2、wireshark / tcpdumpを使用して約数分間パケットをキャプチャし、ランダムパケットが失われたかどうかを分析できます。必要に応じて、パケットファイルをアップロードすることもできます。

3、他のtcpパラメータを調整してみてください。tcp_westwood = 1およびtcp_bic = 1を設定します

解決しました！詳細については、http：//comments.gmane.org/gmane.linux.drivers.e1000.devel/11813を参照してください

要するに、1Gbpsに接続されたサーバーは、TCPの指数関数的増加フェーズ中にトラフィックのバーストを送信し、中間デバイス（何を知っているか）のバッファーをフラッディングするように見えます。これには2つのオプションがあります。

1）各中間ネットワークオペレーターに連絡して、希望する帯域幅とRTTを可能にする適切なバッファーを構成するように依頼します。かなりありそうもない！2）バーストを制限します。

各TCPフローを最大100Mbpsで動作するように制限することを選択しました。ここでの数はかなり任意です。100Mbpsを選択したのは、前のパスが100Mbpsを処理できることがわかっていて、個々のフローにこれ以上必要ないためです。

これが将来の誰かを助けることを願っています。

iperfを使用してUDPで同じテストを繰り返すと、問題が解消します。

ロサンゼルス（1Gbps）からロンドン（1Gbps）：250Mbpsを超えるスループット

問題は解消されたようではなく、おおよそ、パケットの75％がドロップされていますか？TCPが常にスロースタートになる場合、平均帯域幅はかなり低い可能性があります。

ところで、ロンドンからロサンゼルス、ロンドンからロンドンのベンチマークはありますか？