TPLキューの管理

Question

私はさまざまなサーバーのスキャンを実行するサービスを持っています。問題のネットワークは膨大な数（数十万のネットワークノード）になる可能性があります。

私たちによって設計されたキューイング/スレッディングアーキテクチャを使用していますが、効率的ではありません（ジョブがうまく処理されない子を生成できるため）

V2が登場し、TPLの使用を検討しています。それは理想的に適しているようです。

私はthis questionを見ました。その答えは、TPLが処理できるタスクに制限がないことを意味します。私の簡単なテスト（10万のタスクをスピンアップしてTPLに渡す）では、TPLはOut-of-Memory例外をかなり早い段階で回避しました。

スキャンはさまざまな時間がかかりますが、5分/タスクは良い平均です。

巨大なネットワークのスキャンでは、貧弱なサーバーであっても、かなりの時間がかかります。

複数のスキャンサーバー間でスキャンジョブ（複数のDbに格納されている）を分割できるフレームワークが既に用意されていますが、特定のサーバーのTPLに作業をどのくらい正確に渡すべきかという疑問があります。

TPLのキューのサイズを監視して、数百エントリ未満になると（たとえば）上回ることはできますか？これには欠点がありますか？

また、スキャンを一時停止する必要がある状況も処理する必要があります。これは、すでに部分的に処理されている可能性があるタスクをキャンセル/リセットするよりも、TPLに作業を与えない方が簡単だと思われます。

すべての初期タスクは、任意の順序で実行できます。親は実行を開始した後に子を実行する必要がありますが、親がそれらを生成するため、これは問題になることはありません。子供は、任意の順序で実行することができます。このため、私は現在、子タスクを直接TPLに生まれていないDbに書き戻すことを想定しています。これにより、必要に応じて他のサーバーを「盗む」ことができます。

誰もこのようにTPLを使用した経験はありますか？私が気づく必要がある考慮すべき点はありますか？

Answer 1

TPLは小規模な作業単位を開始し、それらを並行して実行しています。この作業の監視、一時停止、または絞り込みについては、ではなく、です。

"仕事"を開始してスレッドを同期するには、TPLが低レベルのツールである必要があります。

要点：TPLタスク！=論理タスク。論理タスクは、あなたのケースのスキャンタスク（「ip-rangeをxからyまでスキャン」）にあります。このようなタスクはではなく、は物理タスク "System.Threading.Task"に対応している必要があります。

TPLがそれらを理解していないために作成できないため、論理タスクを自分でスケジューリング、調整、監視、一時停止する必要があります。

今より実用的な懸念：

1. はTPLは確かにOOMなし100kのタスクを開始することができます。OOMはタスクのコードメモリが使い果たされたために発生しました。
2. スキャニングネットワークは、非同期コードの場合のように聞こえることがあります。スキャンしている間は、並列性が高いうちに結果を待つ可能性が高いからです。おそらく、プロセス内に500個のスレッドを持ち、ネットワークパケットが到着するのを待っているとは限りません。非同期タスクはTPLに適しています。これは、実行するすべてのタスクが純粋にCPUバウンドになるためです。それがTPLのスイートスポットです。