2

LAN 上の多くの Linux サーバー間でマルチキャスト メッセージングを多用しています。多くの遅延が発生しています。私たちは基本的に膨大な数の小さな荷物を送ります。スループットよりもレイテンシに関心があります。マシンはすべて最新のマルチコア (ハイパースレッディングを含めると少なくとも 4 つ、通常は 8 つ、16 つ) のマシンであり、負荷は常に 2.0 以下で、通常は 1.0 未満です。ネットワーク ハードウェアの容量も 50% 未満です。

私たちが目にする遅延は、キューイング遅延のように見えます。パケットは、ジャムしたように見えるまでレイテンシーが急速に増加し始め、その後、通常に戻ります。

メッセージング構造は基本的に次のとおりです。「送信スレッド」で、キューからメッセージを取得し、( を使用してgettimeofday()) タイムスタンプを追加してから、 を呼び出しますsend()。受信プログラムはメッセージを受信し、受信時刻にタイムスタンプを付けて、キューにプッシュします。別のスレッドでキューが処理され、送信タイムスタンプと受信タイムスタンプの違いが分析されます。(タイムスタンプは内部キューの外部に追加されるため、内部キューは問題の一部ではないことに注意してください。)

この問題に対する答えをどこから探し始めればよいのか、私たちは本当に知りません。私たちは Linux の内部構造に精通していません。私たちは、カーネルが送信側または受信側 (またはその両方) でパケットをキューイングまたはバッファリングしていると考えています。しかし、これを追跡して追跡する方法はわかりません。

価値のあるものとして、CentOS 4.x (RHEL カーネル 2.6.9) を使用しています。

4

3 に答える 3

3

これは素晴らしい質問です。*nix のほとんどのフレーバーと同様に、CentOS では、マルチキャスト ソケットごとに UDP 受信/送信バッファーがあります。このバッファーのサイズは sysctl.conf によって制御されます。バッファーのサイズは、/sbin/sysctl -a を呼び出して表示できます。

以下の項目は、デフォルトと最大 udp 受信サイズをバイト単位で示しています。これらの数値が大きいほどバッファリングが多くなり、アプリケーションがデータを消費するのが遅すぎる場合、ネットワーク/カーネルが導入する可能性がある遅延が発生します。データ損失に対する優れた耐性が組み込まれている場合、これらのバッファーを非常に小さくすることができ、上記で説明した遅延の蓄積と回復は見られません。トレードオフは、バッファ オーバーフローによるデータの損失です。これは、すでに見られていることです。

[~]$ /sbin/sysctl -a | メモリ net.core.rmem_default = 16777216 net.core.wmem_default = 16777216 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216

ほとんどの場合、ソケットを作成するときにこれを制御しない限り、default = を最大に設定する必要があります。

最後にできること (カーネルのバージョンによって異なります) は、プロセスまたは少なくともボックス全体の PID の UDP 統計を表示することです。

猫 /proc/net/snmp | grep -i Udp Udp: InDatagrams NoPorts InErrors OutDatagrams Udp: 81658157063 145 616548928 3896986

猫 /proc/PID/net/snmp | grep -i Udp Udp: InDatagrams NoPorts InErrors OutDatagrams Udp: 81658157063 145 616548928 3896986

私の投稿から明らかでない場合、レイテンシーは、アプリケーションが十分な速度でデータを消費せず、カーネルが上記の構造でトラフィックをバッファリングすることを余儀なくされていることが原因です。ネットワーク、カーネル、さらにはネットワーク カードのリング バッファでさえ、レイテンシに影響を与える可能性がありますが、これらすべてのアイテムは通常、数ミリ秒しか追加しません。

ご意見をお聞かせください。パフォーマンスを向上させるためにアプリのどこを見ればよいかについて、さらに詳しい情報を提供できます。

于 2010-02-19T14:38:36.840 に答える
1

パケットは、送信側と受信側のカーネル、NIC、およびネットワーク インフラストラクチャでキューに入る可能性があります。テストして微調整できるアイテムがたくさんあります。

NIC の場合、通常、割り込み合体パラメーターを見つけることができます。これは、NIC がカーネルに通知する前、またはパケットのバッチ処理を待機している間にワイヤに送信するまでに待機する時間です。

Linux の場合、送信と受信の「バッファ」があり、それらが大きいほど、パケットがバッチ操作で処理されるため、待ち時間が長くなる可能性が高くなります。

アーキテクチャと Linux バージョンについては、コンテキスト スイッチのコストが高いことと、ロックまたはプリエンプティブ スケジューリングが有効になっているかどうかを認識する必要があります。プロセス アフィニティを使用してプロセスを特定のコアにロックし、実行中のアプリケーションの数を最小限に抑えることを検討してください。

タイミングを忘れないでください。使用している Linux カーネルのバージョンは、gettimeofday()クロックの精度が非常に低く (2 ～ 4 ミリ秒)、非常に高価な呼び出しです。コア TSC または外部 HPET デバイスからの読み取りなどの代替手段の使用を検討してください。

Intel の図: 代替テキスト http://www.theinquirer.net/IMG/142/96142/latency-580x358.png?1272514422

于 2010-03-19T10:45:15.730 に答える
1

実稼働環境でパケットをキャプチャする必要があると判断した場合は、スイッチで監視ポートを使用し、非実稼働マシンを使用してパケットをキャプチャすることを検討する価値があります。これにより、伝送パスの複数のポイントでパケットをキャプチャして、表示されているものを比較することもできます。

于 2010-03-19T10:57:47.723 に答える