0

同じホストで実行されるtcpクライアントとサーバーがあります。クライアントはメッセージを送信し、サーバーはそれを確認し、クライアントは次のメッセージを送信します。現時点では、未確認の未確認のメッセージは1つだけです。メッセージサイズは1KBです。自宅のコンピューターはCentOs6.3を実行し、オフィスサーバーはRHEL6.3を実行します

上記のクライアントサーバーを自宅のコンピューターで実行すると、毎秒約41kメッセージという非常に一貫したスループットが得られます。オフィスサーバーのCPU負荷はわずか1％です。しかし、同じクライアント/サーバーをオフィスサーバーで実行すると、スループットは18k〜50Kの範囲になります。スループットは大きく変動します。誰かがについての提案を提供できますか

  1. 同じホスト上のtcpの変動の原因として考えられるものは何ですか？

  2. TCPパフォーマンスをデバッグする方法に関するアイデアはありますか？

更新：-私はループバックアドレスを使用しておらず、eth1に割り当てられたIPを使用しています。ただし、最初のリクエストによってルックアップがキャッシュされるため、eth1のIPが/ etc/hostsにないことは問題ではありません。

更新1：-ループバックアドレスで実行すると、同じ変動出力が生成されます。また、を見るとcat /proc/interrupts、NICごとに5つのrxキューと1つのtxキューがあります。変動を引き起こしているのは5rxキューですか？

4

1 に答える 1

0

これが私がすぐに考えることができるいくつかの可能性です：

  • パケットドロップ。これにより、輻輳ウィンドウが縮小します（おそらくローカルホストの場合）
  • アプリケーションのボトルネック。これにより、レシーバーウィンドウが縮小します（最初のウィンドウよりも可能性が低くなります）
  • 何らかの理由でローカルホストに適用されるトラフィックシェーピング。tc qdiscloに何かがあるかどうか試してみてください。iptablesもご覧ください。
  • クライアントまたはサーバーをスロットリングするCPUスケジューリング。時々プロセスをプリエンプトする可能性のあるcgroupsを介してCPUシェアを課していますか？
  • テスト中のどこかで開始し、パケットの到着を遅らせるロギングなど、断続的なオーバーヘッド。または、IDSが突然あなたのアクティビティの監視を開始することを決定します。
  • 短すぎる期間のテストの実行など、測定の不正確さ
  • キューのスラッシングが多すぎるため、ライブロックが低下します。このペーパーは、そのような場合に関する優れた洞察を提供します：https ://cs.uwaterloo.ca/~brecht/papers/getpaper.php?file=usenix-2004.pdf
  • クライアントまたはサーバーのバグ。たとえば、エラーがなかった場合にすべてが完了したと想定するのではなく、send（）が1024を返すことを確認し、そうでない場合は適切なアクションを実行する必要があります。

これをデバッグする方法は次のとおりです。

  • iperf（yum install iperf）などの標準的な測定ツールを使用することから始めます。次にiperf -s、ある端末でiperf -c localhost、別の端末で。安定した結果が得られますか？そうであれば、問題はクライアントとサーバーのバグです。
  • TCPの場合、iperfはウィンドウサイズを定期的に印刷するなどの診断を提供します。lo/ proc / sys / ipv4で、他の統計情報とともに、パケットドロップのインターフェイスを確認することもできます。
于 2013-01-07T05:01:19.613 に答える