問題タブ [threadpool]

私はサーバーを作成しており、リクエストを受信すると、の各アクションを別々のスレッドに送信します。ほとんどすべてのリクエストがデータベースクエリを実行するため、これを行います。スレッドプールライブラリを使用して、スレッドの構築/破棄を削減しています。

私の質問は、このようなI / Oスレッドの適切なカットオフポイントは何ですか？大まかな見積もりだとは思いますが、何百人も話しているのでしょうか。数千？

このカットオフがどうなるかをどうやって理解するのでしょうか？

編集：

ご回答ありがとうございました。スレッド数の上限を確認するためにテストする必要があるようです。問題は、しかし、私がその上限に達したことをどうやって知ることができるかということです。正確に何を測定する必要がありますか？

優先度の異なるいくつかのメソッドを非同期で呼び出す必要があります。

私の最初のアイデアは、ThreadPool を使用して、スレッドの優先度を次のように変更することでした。

それは機能しますか、それとも何をお勧めしますか?

インタラクティブなアプリケーションで、CPU を大量に消費するマルチタスク可能なジョブを管理する必要があります。背景として、私の特定のアプリケーションはエンジニアリング設計インターフェースです。ユーザーがモデルのさまざまなパラメーターやオプションを微調整すると、複数のシミュレーションがバックグラウンドで実行され、完了時に結果が表示されます。ユーザーがまだ値を編集している可能性もあります。複数のシミュレーションにはさまざまな時間がかかるため (ミリ秒のものもあれば、5 秒かかるものもあれば、10 分かかるものもあります)、基本的にはフィードバックをできるだけ早く表示することですが、多くの場合、以前に開始されたが不要になったジョブは中止されます。ユーザーの変更のうち、既にそれらが無効になっています。ユーザーの変更が異なれば、異なる計算が無効になる可能性があるため、いつでも 10 の異なるシミュレーションを実行できます。

この種のアプリケーションを処理するためのコード レベルの方法は、ある種のマルチスレッド ジョブ キューであると確信しています。これには、実行のためにジョブを送信する機能、タスクの優先度を設定する機能、ジョブが完了するのを待つ機能、依存関係を指定する機能 (このジョブを実行しますが、ジョブ X とジョブ Y が完了した後でのみ)、いくつかの基準に適合するジョブのサブセットをキャンセルする機能、何をクエリする機能が含まれます。ジョブが残り、ワーカー スレッドの数と優先順位が設定されます。また、マルチプラットフォームのサポートも非常に便利です。

これらはソフトウェアの新しいアイデアや要望ではありませんが、私はアプリケーションの初期設計段階にあり、そのようなタスクを管理するためにどのライブラリを使用するかを選択する必要があります。私は過去に C で大まかなスレッド マネージャーを作成しましたが (これは通過儀礼だと思います)、自分の以前のハックではなく、最新のツールを使用して作業を行いたいと考えています。

最初に考えたのは、OpenMPを実行することですが、それが私が望むものかどうかはわかりません。OpenMP は、細かいレベルでの並列化、ループの自動展開などに最適です。マルチプラットフォームである一方で、#pragmas でコードに侵入します。しかし、ほとんどの場合、大規模なタスクを管理するようには設計されていません。特に、保留中のジョブをキャンセルしたり、依存関係を指定したりします。可能ですが、エレガントではありません。

Google Chrome では、最も些細なタスクでもこのようなジョブ マネージャーを使用していることに気付きました。設計の目標は、ユーザー インタラクション スレッドを可能な限り軽量かつ機敏に保つことであるように思われるため、非同期で生成できるものはすべてそうする必要があります。Chrome のソースを見ると、これは一般的なライブラリではないように見えますが、設計が非同期起動を使用して対話を高速に保つ方法を見るのは興味深いことです。これは、私がやっていることと似てきています。

まだ他のオプションがあります:

Surge.Act:ジョブを定義するための Boost のようなライブラリ。OpenMP で構築されていますが、依存関係の連鎖が可能で、これは素晴らしいことです。クエリを実行したり、ジョブをキャンセルしたりできるマネージャーがいるような気がしないようです。古いプロジェクトなので、それに依存するのは怖いです。

Job Queueは私が考えているものにかなり近いですが、これは 5 年前の記事であり、サポートされているライブラリではありません。

Boost.threadsには、プラットフォームに依存しない優れた同期がありますが、それはジョブ マネージャーではありません。POCOは、タスクを起動するための非常にクリーンな設計を備えていますが、タスクをチェーンするための完全なマネージャーではありません。（私はPOCOを過小評価しているかもしれませんが）。

そのため、利用可能なオプションはありますが、私は満足しておらず、自分のライブラリをもう一度ロールアップしたいという衝動を感じています. しかし、私はむしろすでに存在するものを使用したいと思います。検索した後でも（ここSOとネットで）、適切に感じるものは何も見つかりませんでしたが、これはしばしば必要とされる一種のツールであるに違いないので、コミュニティライブラリまたは少なくとも一般的なデザインが確実にあります. SO にはjob queuesに関する投稿がいくつかありましたが、適合するものは何もありません。

ここでの私の投稿は、私が見逃した既存のツール、および/またはそのような独自のマルチスレッド ジョブ キューをどのように展開したかをすべて質問することです。

次の擬似を観察します。

プールされたスレッドのいずれかで例外が発生した場合、ASP.NET WebApp はデッドロック状態になります。応答ストリームで渡される例外情報はありません。これを防ぐための提案を求めています。固定のタイムアウトは許容されます。timeConsumingOpHandler が WaitHandle を Set() するとします。

timeConsumingOpHandler 全体が try-catch-finally ブロックにラップされ、finally セクションで WaitHandle が Set() になります。それでも、デッドロックが発生します。

アプリケーションで不可解な動作が発生しています。

スレッドを作成します。これをワーカーと呼びましょう。これは、通信要求の処理を担当します。スレッドが要求を消費してメッセージを送信している間、クライアントはパイプに書き込みます。

これで、スレッドのメイン ループは次のようになります。

ここで、コールバックは client_id にアクセスする必要があります (私が書いたものよりも少し複雑ですが、問題は、コールバックが object_id を受け取ることです。BeginSend がへの呼び出しであると想定してください)。UdpClient.BeginSend

clientsObjects[object_id] = client_id;ロックが存在するのは、コールバックが非常に高速に起動する可能性があるため、実行前に実際に発生する可能性があるためです...

わかりました、今..問題は、それが機能していないことです。まあ、時々機能します...なぜですか？BeginSend を実行しているスレッドとコールバックを実行しているスレッドの ManagedThreadIds をトレースすると、同じ ThreadId を持っていることが時々わかります!!

それは可能ですか？どうすればそれが起こりますか？私が間違っていることについて何か提案はありますか?

コメント: 実際のコードはまったく同じではありません。Transport は UDPClient のラッパーであり、トランスポート層を簡単に変更できます。ロックは実際にはロックではなくスピンロックです ... しかし、概念自体は多かれ少なかれ私が書き留めたものです.

着信要求ごとに個別のスレッドを使用する REST サービス用の古い Java コードがあります。つまり、メイン ループは socket.accept() でループし、ソケットを Runnable に渡します。Runnable は独自のバックグラウンド スレッドを起動し、それ自体で run を呼び出します。これはしばらくの間見事にうまく機能していましたが、最近、要求を処理するための受け入れの遅れが高負荷下で受け入れられなくなることに気付きました。見事にうまく言えば、CPU をあまり使用せずに 1 秒あたり 100 ～ 200 のリクエストを処理していたことを意味します。パフォーマンスが低下したのは、他のデーモンも負荷を追加していたときだけで、負荷が 5 を超えたのは 1 回だけでした。マシンが他のプロセスの組み合わせから高い負荷 (5-8) にさらされていた場合、受け入れから処理までの時間が途方もなく長くなりました ( 500 ミリ秒から 3000 ミリ秒）、実際の処理は 10 ミリ秒未満のままでした。

.NET のスレッドプールに慣れていたので、スレッドの作成が原因であると想定し、Java で同じパターンを適用すると考えました。今私の Runnable は ThreadPool.Executor で実行されます (そしてプールは ArrayBlockingQueue を使用します)。繰り返しになりますが、マシンの負荷が高くならない限り、ほとんどのシナリオでうまく機能します。その後、ランナブルの作成から run() が呼び出されるまでの時間は、ほぼ同じばかげたタイミングを示します。さらに悪いことに、スレッドプール ロジックを導入すると、システム負荷がほぼ 2 倍 (10-16) になりました。そのため、負荷が 2 倍になると同じ遅延の問題が発生します。

私の疑いでは、キューのロック競合は、ロックのない以前の新しいスレッドの起動コストよりも悪いということです。新しいスレッドとスレッドプールの経験を共有できる人はいますか? そして、私の疑いが正しければ、ロック競合なしでスレッドプールを処理するための代替アプローチを誰かが持っていますか?

スレッド化がどれだけ役立つかわからず、IO が問題にならないように見えるので、システム全体をシングルスレッド化したくなるかもしれませんが、長寿命のリクエストがいくつかあります。すべてをブロックします。

ありがとう、アルネ

更新: 切り替えてExecutors.newFixedThreadPool(100);、同じ処理能力を維持しながら、負荷はすぐにほぼ 2 倍になり、12 時間実行すると、負荷が常に 2 倍にとどまることがわかりました。私の場合、リクエストごとの新しいスレッドの方が安いと思います。

Java のスレッディングと並行処理の世界に関しては、私はかなり世間知らずです。私は現在、学ぼうとしています。同時実行がどのように機能するかを理解するために、簡単な例を作成しました。

これが私のコードです：

コードで 0 ～ 99 の数字を順番に出力するにはどうすればよいですか?