問題タブ [disruptor-pattern]

テキストファイルを読み込んでデータベースに挿入しようとしていますDisruptor.

しかし、CPU 使用率が高すぎることがわかりました (topコマンドによると 200%)。

パフォーマンス チューニングとスレッド ダンプ分析は初めてです。何が問題なのかわかりません。

そこでtop -H、2 つの最も高いスレッド (両方とも 99%) を実行して見つけ、スレッド ダンプを見つけます。

基本的に、これら 2 つのスレッドはデータを Disruptor にパブリッシュします。私はこのように作成Disruptorします：

スレッド ダンプを分析して、高い CPU 使用率の根本原因を見つけてください。

マルチ プロデューサーと x86 Linux で実行されている単一のコンシューマーを持つリング バッファーのような lmax ディスラプターでコンシューマーが遅い場合の対処法について質問があります。リング バッファ パターンのような lmax を使用すると、常にデータを上書きしますが、消費者が遅い場合はどうなりますか。したがって、たとえば 10 サイズのリング バッファ 0 ～ 9 のリング スロットでコンシューマがスロット 5 にあり、ライターがバッファのスロット 5 でもあるスロット 15 の書き込みを開始する準備ができている場合をどのように処理しますか (つまり、スロット5 = 15 % 10 )? ライターが入ってきた順にデータを生成し、クライアントが同じ順序でデータを受け取るように、これを処理する一般的な方法は何ですか? それは本当に私の質問です。以下は私の設計に関する詳細であり、問​​題なく動作しますが、現在この問題を処理する良い方法がありません。

設計仕様

リング バッファーがあり、現在、設計には複数のプロデューサー スレッドと 1 つのコンシューマー スレッドがあります。デザインのこの部分は既存のものであり、現在変更することはできません。ロック フリー リング バッファを使用して、既存のキューイング システムを削除しようとしています。私が持っているものは次のとおりです。

コードは x86 Linux で実行され、ライター用に複数のスレッドが実行され、リーダー用に 1 つのスレッドが実行されます。リーダーとライターは 1 スロット離れて開始するstd::atomic<uint64_t>ため、リーダーはスロット 0 から開始し、ライターはスロット 1 から開始し、各ライターは最初に、以下に示すfetch_add(1, std::memory_order::memory_order_acq_rel)呼び出しによってライター シーケンスでアトミックを実行してスロットを要求incrementSequenceし、その後、compare_and_swap ループを使用します。このスロットが利用可能であることをクライアントに知らせるためにリーダー シーケンスを更新するには、 を参照してくださいupdateSequence 。

Java アプリケーションで log4j2 をディスラプターと共に使用しようとしています。クラスパスに次のjarファイルがあります。

1. log4j-api-2.0-rc2.jar
2. log4j-core-2.0-rc2.jar
3. 破壊者-3.2.0.jar

私のJavaクラスでは、次のことを行ってテストします。

私の log4j2.xml ファイルは次のとおりです。

アプリケーションを実行すると、次のエラーが表示されます (ログ出力なし)。

私は Google Disruptor のソースを見ていましたが、次のような観察結果が見つかりました。

次の 2 つの方法は、どちらも同じ操作を行っています。そのうちの 1 つは非公開ですが、メソッドが重複している原因については実際には答えていません。

プログラマーの読みやすさのためだけですか？

私は、オファー/ポーリングごとに同期や CAS 操作を行わずに、1 つのコンシューマーとプロデューサーが同時にキューから要素をオファー/ポーリングできるようにするキューを開発しました。代わりに、キューの末尾セクションが空の場合、1 つのアトミック操作のみが必要です。このキューは、キューがバッファリングされ、コンシューマーがプロデューサーに追いつかない場合に、レイテンシーを短縮することを目的としています。

質問では、実装をレビューしたいと思います（コードはまだ他の誰にもレビューされていないので、セカンドオピニオンを取得するのは素晴らしいことです）、レイテンシを大幅に削減すると思われる使用パターンと、このアーキテクチャができるかどうかについて議論したいと思いますおそらく LMAX ディスラプターよりも高速に実行されます。

コードは github にあります: https://github.com/aranhakki/experimental-performance/blob/master/java/src/concurrency/messaging/ConcurrentPollOfferArrayQueue.java

複数のプロデューサーとコンシューマーがすべて同じキューを参照する代わりに、これらのキューの多くを使用することで、待ち時間を大幅に短縮できると思います。

プロデューサー A、B、C がすべて単一のキュー Q を参照し、コンシューマー E、E、および F がすべて同じキューを参照しているとします。これにより、次の一連の関係が発生し、多くの競合が発生します。

A は Q に書き込みます

B は Q に書き込みます

C は Q に書き込みます

E は Q に書き込みます

D は Q に書き込みます

F は Q に書き込みます

私が開発したキューを使用すると、各プロデューサーと単一のコンシューマー集約スレッドの間にキューを作成できます。このスレッドは、各プロデューサー キューの末尾の要素を取得し、それらをコンシューマー キューの先頭に配置します。これにより、メモリのセクションへのライターが 1 つしかないため、競合が大幅に減少します。リレーションシップは次のようになります。

A writesTo headOf(AQ)

B writesTo headOf(BQ)

C writesTo headOf(CQ)

ConsumerAggregationThread writesTo tailOf(AQ)

ConsumerAggregationThread writesTo tailOf(BQ)

ConsumerAggregationThread writesTo tailOf(CQ)

ConsumerAggregationThread writesTo headOf(EQ)

ConsumerAggregationThread writesTo headOf(FQ)

ConsumerAggregationThread writesTo headOf(GQ)

E writesTo tailOf(EQ)

F writesTo tailOf(FQ)

G writesTo tailOf(GQ)

上記の関係により、単一ライターの原則が保証されます。

私はあなたの考えを聞きたいです。

クライアント (ボットネット サーバー) は、TCP ソケットを介してサーバー (ディスラプター) に連続メッセージを送信しようとしていますが、ディスラプターで受信されるメッセージは 1 つだけです。Disruptor は、ボットネット サーバーによって作成されるスレッドです。

コード: ボットネット サーバー

ディスラプター run()

Disruptor リング バッファ内のイベントに Javolution Struct クラスを使用しています。これが、メッセージをよりキャッシュしやすくする最も簡単な方法のように思えました。ただし、これまで Javolution を使用した経験はなく、Javolution のチューニングに関するチュートリアルに関する資料はほとんど見つかりませんでした。

私の質問は次のとおりです。

1. このアプローチ (つまり、Javolution Structs をイベント クラスとして使用すること) で注意すべき欠点は何ですか?

2. 注意すべき Javolution 固有の最適化はありますか? これまでに見つけて使用した唯一の調整パラメーターは次のとおりです。

   @Override public boolean isPacked() { true を返します。}

前もって感謝します

- 編集 -

与えるか取るか、クラスは次のようになります。