4

オプションでスレッドプールmaxthreadsをオーバーライドできるいくつかの（c＃3.5）バッチ処理コードを作成しました。スレッドセーフではないかなり重いリソースを使用するため、アクティブなスレッドごとにアイテムを使用して「リソースプール」を維持する必要があります。消費するアプリケーションは、バッチプロセッサが使用するスレッドの数に制限を設定できます。これにより、が呼び出されますThreadPool.SetMaxThreads()。手動で制限を設定すると、デフォルト設定のままにするよりもパフォーマンスが向上するかどうかをテストするためにこれを行っています。

私の質問は、バッチ処理コードを使用するたびに、maxthreadsをアプリケーションの以前の値にリセットする必要があるかどうかです。1日を通して断続的に、場合によっては数千回も呼び出されます。MaxThreadsの制限は、アプリケーションが再起動されるか、別の値に設定されるまで永久に持続しますか、それとも自動的にリセットされますか？

これは私のテストハーネスでは実際には問題ではありませんが、本番環境で使用するためにバッチが完了した後に他のリソースが破棄されたときに、スレッドプールを「リセット」するようにコードを更新する必要があるかどうか疑問に思っています。オーバーライドしたままにしておくことには何か影響がありますか？

最後に、1つの.netアプリケーションでスレッドプールを設定すると、ボックス上のすべてのアプリケーションに設定されますか、それともその単一のアプリのコンテキストにのみ設定されますか？

4

3 に答える 3

3

TL; DR：使用しないでくださいSetMaxThreads。

この設定はプロセスごとです。他のプロセスは影響を受けませんが、アプリケーション全体は影響を受けます。これは「ローカル問題のグローバルソリューション」と呼ばれ、悪いことと考えられています。

この設定の影響を受けるのはアプリの一部だけですが、アプリ全体に影響を与えています。

たとえば、同時実行を制限するためにmax-threadsを低い値に設定すると、ASP.NET要求スレッドなどを含むアプリケーション全体の残りの部分が不足します。

そのため、私は常にそのような問題をローカルで解決することを好みます。多くのTPLプリミティブ（PLINQ、Parallel。*）を使用すると、最大の並列度を設定できます。単純なタスクの場合、固定数のスレッド（ParallelExtrasで利用可能なコード）を持つカスタムタスクスケジューラを使用できます。

于 2012-08-24T10:51:37.990 に答える
1

まず、msdnが言うように：

「スレッドプール内のスレッドの最大数を変更するときは注意してください。コードにはメリットがあるかもしれませんが、変更は使用するコードライブラリに悪影響を与える可能性があります。

スレッドプールサイズの設定が大きすぎると、パフォーマンスの問題が発生する可能性があります。同時に実行しているスレッドが多すぎると、タスク切り替えのオーバーヘッドが重要な要素になります。」

また、ホストされたソリューションを使用すると、IISによってスレッドを制御できます（おそらく制限されるか、変更されないようにすることもできます）。これは、IISのバージョンに応じて、ボックス上のすべてのアプリ、または継承された設定が変更された場合は個々のアプリに適用できます。

PS詳細については、この同様の投稿を参照してください。興味深い読み物については、スレッドプールスロットリングリンクを参照してください。クリックしてください。

于 2012-08-24T10:40:31.853 に答える
1

レベルを下げると、スレッドプールはスレッドを強制終了し、（GoodThing™）メモリ使用量（これらすべてのスレッドのスタック）を削減します。（BadThing™）は、レベルを再度上げるときにスレッドを再度作成する必要があることを意味します。 。また、その間にスレッドプールを使用するタスクがたくさんある場合（BadThing™）、プールが過度に寛大になる可能性がありますが、プールの全体的な使用が実際に優れているほど十分にブロックされている可能性があります（GoodThing™ ）。ただし、その期間に使用された使用量が少なすぎて、違いを生むことができない可能性があります（ええ、IrrelevantThing™）。

全体として、私はおそらく、アプリケーションが起動する忙しい期間に必要になるだけプールを高く設定し、それをそのままにしておきます。他の期間中にレベルを下げることは、アプリケーションの残りの実行中にパフォーマンスの問題がある場合に実験する価値がありますが、これらの期間中にメモリまたはスレッドの使用が懸念されない限り、これらのスレッドが使用されるため、私はそうしません。やっぱり将来も。レベルを一度設定するだけの方が簡単で、なぜそうでないのかを説明できる場合を除いて、常に簡単な方が良いです（「できるだけ簡単ですが、簡単ではありません」）。

編集：

私は質問に対する正解として上記を書きましたが、max-threadsにまったく触れないことを示唆する他の答えは本当にお金になります。本当に非常に多くのスレッドが本当に必要な場合は、自分でスレッドを作成します（スピンアップ時間の重要性に応じて、プールしないか、自分でプールを処理します）。しかし、その前に、代替案を検討してください。これは、多くの場合、最善のアプローチでもないためです。

于 2012-08-24T10:23:29.870 に答える