より良いTCP「高遅延ネットワーク」でのパフォーマンス
Linuxマシン間の「高遅延ネットワーク」でのTCPスループットを改善しようとしています。
tcp_mem、tcp_wmemおよびtcp_rmemから「8192 7061504 7061504」に。
私はrmem_max、wmem_max、rmem_defaultおよびwmem_defaultから「7061504」に。
私はnetdev_max_backlogおよびtxqueuelen〜10000。
私はtcp_congestion_controlから「スケーラブル」。
「nist」（cnistnet）を使用して100ミリ秒の遅延をシミュレートしています。到達する帯域幅は約200 mbpsです（遅延なしでは約790 mbpsに到達します）。
私はiperfを使用してテストを実行し、TCPTraceを使用して結果を分析しています。これは私が得たものです。
受信側：
最大勝利広告：5294720バイト
avg win adv：5273959バイト
sack pkts sent：0
送信側：
実際のデータバイト：3085179704
rexmtデータバイト：9018144
最大オーウィン：5294577バイト
avg owin：3317125バイト
RTT分：19.2ミリ秒
RTT最大：218.2ミリ秒
RTT平均：98.0ミリ秒
なぜ200mbpsしか到達しないのですか？ 「owin」には何らかの関係があると思いますが、よくわかりません（これらの結果は2分のテストの結果です。1分のテストの「avg owin」は1552900でした）…
遅延が100msであってもスループットがほぼ790mbpsであると期待するのは間違っていますか？
（ウィンドウ構成でより大きな数値を使用しようとしましたが、効果がないようです）
これは一般的なTCP「Long Fat Pipe」と呼ばれる問題です。あなたがそのフレーズをググると、TCPはこの問題に関する多くの情報を見つける可能な解決策。
このスレッド には、Linuxのチューニングに関する計算と提案がたくさんありますTCPこの種のスタック。
サイト
http://www.psc.edu/networking/projects/tcptune/
最近のLinuxではautotunes TCP=設定なので、値をいじっても改善されない可能性が高いと述べています。
そうは言っても、100ミリ秒と広い帯域幅（少なくとも790 mbps）を併用すると、巨大なBDPが発生する可能性があるため、自動調整によって何かが間違っていると判断され、十分ではない可能性があります。
そのリンクのbandwidth-delay-productを実際に一致させるようにiperfウィンドウサイズを設定してみてください。だから平均RTT * 1Gbpsはおおよそ10MBを与えるはずです。それが物事を改善するかどうかを確認します。
何が起こっているのかを本当に理解し始めることができる唯一の方法は、より多くのデータを取得することです。 sarパッケージからiostatを使用してシステムレベルのビュー（cpu、メモリ、割り込みなど）を取得することをお勧めします。また、Wiresharkまたはtcpdumpを使用してパケットダンプを取得する必要があります。その後、Wiresharkを使用して、このためのツールがたくさんあるので、それを分析できます。時間の経過に伴うウィンドウサイズ、パケット損失などをグラフ化できます。
高遅延リンクでのわずかなパケット損失でさえ、帯域幅をかなり損なう傾向があります。シミュレーションされていますが、これは少し奇妙です。小さなパケットがたくさんあると、高い割り込みが発生する可能性があります（それらも同様にシミュレートされますか？）。
つまり、簡単に言うと、TCPDumpとSarを取得して、パケットレベルとシステムリソースで何が行われているのかを確認します。
このマシンにはどのくらいのメモリがありますか？ tcp_mem設定は異常なようです。TCPデータをグローバルに28gb（7061504 * 4kb）構成しました。（しかし、これはほとんどの場合、少数ソケットのテスト実行の制限。tcp_memをtcp_xmemの値に設定すると、非常に一般的な誤解が生じるため、このことについてお伝えしたいと思います。
デフォルトで設定した7MBは問題ないようです。ただし、最大遅延パイプでは、最大値がはるかに高くなる場合があります。テストでは、tcp_wmemおよびtcp_rmemの最大数として64MBを使用します。これが制限要因であることを除外できます。 （これはバッファーを膨らませるので、並行性が制限されていて、接続のジッターとドロップが低い場合にのみ機能します）。