マルチスレッドのソフトウェアがあります。ソース スレッドは、一連の並列タスク (各タスクにはいくつかの処理とサード パート API との対話が含まれます) を開始し、それらの一部またはすべてが完了するのを待ちます。
各スレッドは、作業を完了するのに 3 ～ 30 秒かかります。
(本番環境では) の呼び出しThreadPool.QueueUserWorkItemとスレッドの実際の開始の間に最大 10 秒の遅延が発生する可能性があることを発見したため、スレッドプールで使用可能なスレッドの供給が飽和状態になっていると考えられます。その制限に関するコメントについては、こちらを参照してください: System.Threading.ThreadPool.SetMaxThreads のデフォルト値
これらのさまざまな数のスレッドを追跡できるようにして、さまざまな変更を加えたら、何かを指して「ほら、すべてのスレッドを使い果たした問題を解決した」と言うことができるようにしたいと考えています。
この MSDN ページ: https://msdn.microsoft.com/en-us/library/ff650682.aspxは、この種のものを追跡するカウンターがないことを意味し、DIY カウンターの推奨される実装を提供するだけです。
一方、このページ: http://blogs.iis.net/mailant/new-worker-process-performance-counters-in-iis7はカウンターが存在すると言っていますか? 「Maximum Threads」、「Total Threads」、および「Active Threads」が関連するはずだと言っているようです。これらは次のことを意味していると思います。
- 「最大」: 新しいスレッドを作成する前に古いスレッドが終了するのを待機し始める前に、TP が作成できるスレッドの数。
- 「アクティブ」: 任意の時点で実際にプログラム コードを実行しているスレッドの数。
- "合計"： ？？これは「アクティブ」+「開始されたが外部リソースを待機しているスレッドの数」だったと思いますか? 私たちの場合はサードパーティの API ですが、一般的にはディスク IO や DB アクセスなどである可能性があります。
Perf Monitorを開いて、「新しいカウンターを追加」>「W3SVC_W3WP」>これら3つの特定のカウンターを選択>特定のプロセスを選択>「追加」>「OK」でこれらを確認しようとしました。
次に、Perf Monitor グラフは次のことを示しています。 最大 = 256 合計 = 16 アクティブ = 0 !?
それは…ありそうもない？カウンターを誤解しているか、Perf Monitor の構成を誤っていると思いますか?
次の試みは、プロセスのタスク マネージャーの「スレッド」列を調べることでした (IIS マネージャーから PID を介して正しい w3wp プロセスを識別します)。これは通常、100 ～ 150 のスレッドがあることを示していますが、実際にプロセスをスラッシングすると (実行中の API エンドポイントをスパムします)、256 を超える数を取得できます (ある時点で 264 で見ました)。
誰でもこれに光を当てることができますか？
基本的に私の質問は、ThreadPool.QueueUserWorkItemThreadPool のスレッドの可用性の状態を追跡するための最良の方法は何かということです。