17

私は最近、ネットワーク パフォーマンスとループバック パフォーマンスを比較するいくつかのパフォーマンス テストを実行しているときに、興味深い TCP パフォーマンスの問題に遭遇しました。私の場合、ネットワークのパフォーマンスがループバックのパフォーマンスを上回りました (1Gig ネットワーク、同じサブネット)。私が対処している場合、待ち時間が重要であるため、TCP_NODELAY が有効になっています。私たちが思いついた最良の理論は、TCP 輻輳制御がパケットを滞らせているというものです。いくつかのパケット分析を行ったところ、パケットが保持されていることが明確にわかりますが、その理由は明らかではありません。さて、質問は...

1) ループバックを介した通信がネットワークを介した通信よりも遅くなるのは、どのような場合で、その理由は何ですか?

2) できるだけ速く送信する場合、TCP_NODELAY の切り替えがネットワーク経由よりもループバック経由の最大スループットに大きな影響を与えるのはなぜですか?

3) パフォーマンスの低下の潜在的な原因として、TCP 輻輳制御をどのように検出して分析できますか?

4) この現象の理由について、他の説を持っている人はいますか? はいの場合、理論を証明する方法はありますか?

以下は、単純なポイント ツー ポイント C++ アプリによって生成されたサンプル データです。

トランスポート メッセージ サイズ (バイト) TCP NoDelay 送信バッファ (バイト) 送信側ホスト 受信側ホスト スループット (バイト/秒) メッセージ レート (メッセージ/秒)
TCP 128 オン 16777216 ホスト A ホスト B 118085994 922546
TCP 128 オフ 16777216 ホスト A ホスト B 118072006 922437
TCP 128 オン 4096 ホスト A ホスト B 11097417 86698
TCP 128 オフ 4096 ホスト A ホスト B 62441935 487827
TCP 128 オン 16777216 ホスト A ホスト A 20606417 160987
TCP 128 オフ 16777216 ホスト A ホスト A 239580949 1871726
TCP 128 オン 4096 ホスト A ホスト A 18053364 141041
TCP 128 オフ 4096 ホスト A ホスト A 214148304 1673033
UnixStream 128 - 16777216 ホスト A ホスト A 89215454 696995
UnixDatagram 128 - 16777216 ホスト A ホスト A 41275468 322464
NamedPipe 128 - - HostA HostA 73488749 574130

以下に、さらに役立つ情報をいくつか示します。

  • この問題は小さなメッセージでのみ見られます
  • HostA と HostB はどちらも同じハードウェア キットを使用しています (Xeon X5550@2.67GHz、合計 32 コア/128 ギグ メモリ/1 ギグ NIC)
  • OS は RHEL 5.4 カーネル 2.6.18-164.2.1.el5)

ありがとうございました

4

3 に答える 3

9

1)ループバックを介した通信がネットワークを介した通信よりも遅くなるのは、どのような場合で、その理由は何ですか?

ループバックは、両方の tx+rx のパケット setup+tcp chksum 計算を同じマシンに配置するため、2 倍の処理を行う必要がありますが、2 台のマシンでは tx/rx をそれらの間で分割します。これは、ループバックに悪影響を及ぼす可能性があります。

2)できるだけ速く送信する場合、 TCP_NODELAYの切り替えがネットワーク経由よりもループバック経由の最大スループットに大きな影響を与えるのはなぜですか?

どのようにしてこの結論に達したのかはわかりませんが、ループバックとネットワークの実装は非常に異なっており、それらを限界まで押し込もうとすると、さまざまな問題が発生します。ループバック インターフェイス (1 への回答で述べたように) は、同じマシンで tx+rx 処理のオーバーヘッドを引き起こします。一方、NIC には、循環バッファなどに保持できる未処理のパケットの数に関する制限があり、これがまったく異なるボトルネックを引き起こします (これは、チップごとに大きく異なり、また、間にあるスイッチによっても異なります)。彼ら）

3)パフォーマンスの低下の潜在的な原因として、TCP 輻輳制御をどのように検出して分析できますか?

輻輳制御は、パケット損失が発生した場合にのみ開始されます。パケット損失が発生していますか? それ以外の場合は、おそらく tcp ウィンドウ サイズとネットワーク レイテンシの要因の制限に達している可能性があります。

4)この現象の理由について、他の説を持っている人はいますか? はいの場合、理論を証明する方法はありますか?

ここで言及されている現象がわかりません。あなたのテーブルにあるのは、送信バッファが大きいソケットがいくつかあるということだけです。これは完全に正当なものです。高速なマシンでは、アプリケーションはネットワークが送り出すよりも多くのデータを確実に生成できるため、ここで何を問題として分類しているのかわかりません。

最後に 1 つ: メッセージが小さいと、次のようなさまざまな理由で、ネットワークのパフォーマンスが大幅に低下します。

  • パケットごとに一定のオーバーヘッド (mac+ip+tcp ヘッダーの場合) があり、ペイロードが小さいほどオーバーヘッドが大きくなります。
  • 多くの NIC 制限は、未処理のパケットの数に関連しています。つまり、小さいパケットを使用すると、はるかに少ないデータで NIC のボトルネックにぶつかることになります。
  • ネットワーク自体をパケットごとのオーバーヘッドとして処理するため、ネットワークを通過できるデータの最大量は、パケットのサイズに依存します。
于 2011-05-12T22:28:01.540 に答える