5

マルチキャスト経由で UDP パケットを送信するサーバーと、それらのマルチキャスト パケットにリストされている多数のクライアントがあります。各パケットのサイズは 1040 バイトの固定サイズで、サーバーから送信されるデータ全体のサイズは 3G バイトです。

私の環境は次のとおりです。

1 ギガビット イーサネット ネットワーク

40 のノード、1 つの送信側ノードおよび 39 の受信側ノード。すべてのノードのハードウェア構成は同じです: 2 つの AMD CPU、各 CPU には 2 つのコア @2,6GHz があります。

クライアント側では、1 つのスレッドがソケットを読み取り、データをキューに入れます。追加の 1 つのスレッドがキューからデータをポップし、軽い処理を行います。

マルチキャスト送信中に、ノード側で 30% のパケット ドロップ率を認識します。netstat –su 統計を観察することで、クライアント アプリケーションによって欠落しているパケットは、netstat 出力の RcvbufErrors 値と同じであると言えます。

これは、ソケット バッファがいっぱいになったため、不足しているすべてのパケットが OS によってドロップされたことを意味しますが、キャプチャ スレッドがバッファを時間内に読み取れない理由がわかりません。送信中、4 つのコアのうち 2 つが 75% 使用され、残りはスリープ状態です。これらのノードを使用しているのは私だけですが、この種のマシンは 1 ギガビットの帯域幅を問題なく処理できると思います。amd cpus に g++ コンパイラ フラグを追加することで、既にいくつかの最適化を行っています。これにより、パケット ドロップ率が 10% に減少しますが、それでも私の意見では高すぎます。

もちろん、UDP が信頼できないことはわかっています。私は独自の修正プロトコルを持っています。

管理権限がないため、システム パラメータを変更することはできません。

どうすればパフォーマンスを向上させることができますか？

編集:ソケットを読み取っている2つのスレッドを使用して、この問題を解決しました。recv ソケット バッファがいっぱいになることがあります。しかし、平均ドロップは1%未満なので、対処するのに問題はありません。

4

3 に答える 3

4

パケット ドロップが発生するコンポーネントが多数あるため、Linux でネットワーク ドロップを追跡するのは少し難しい場合があります。これらは、ハードウェア レベル、ネットワーク デバイス サブシステム、またはプロトコル層で発生する可能性があります。

各コンポーネントを監視および調整する方法を説明する非常に詳細なブログ投稿を書きました。監視と調整が必要なさまざまなコンポーネントが非常に多いため、ここで簡潔な回答として要約するのは少し難しいです。

于 2016-06-23T01:30:04.057 に答える
2

ソケット読み取りループから不要なものをすべて削除することは別として、次のようになります。

  • でソケット受信バッファを増やしますsetsockopt(2)。
  • カーネルがサポートしている場合は、を使用recvmmsg(2)して、システムコールとカーネルユーザーランドのコピーの数を減らします。
  • エッジトリガーによるノンブロッキングアプローチを検討してくださいepoll(7)。
  • ここで本当にスレッドが必要かどうかを確認してください。ロック/同期には非常にコストがかかります。
于 2012-06-05T15:36:06.887 に答える
-1

「クライアント側では、1 つのスレッドがソケットを読み取り、データをキューに入れます。」 問題はこのスレッドにあると思います。メッセージの受信速度が十分ではありません。データをキューに入れるときにミューテックスを取得するなど、他のことに時間がかかりすぎます。ロックフリー キューを使用するなど、キューの操作を最適化してください。

于 2016-03-01T09:35:12.050 に答える