スレッドの数はどれくらいが多すぎるのでしょうか? 質問する

スレッドが2 つだと多すぎると言う人もいるでしょうが、私はそうは思いません :-)

これが私のアドバイスです。推測するのではなく、測定してください。1つの提案は、これを構成可能にして、最初に 100 に設定し、その後ソフトウェアを一般にリリースして何が起こるかを監視することです。

スレッド使用量が 3 でピークに達した場合、100 は多すぎます。1 日の大半で 100 のままである場合は、200 に増やして何が起こるかを確認します。

実際には、コード自体に使用状況を監視し、次回起動時に構成を調整させることもできますが、それはおそらくやりすぎです。

明確化と詳細化のため:

独自のスレッド プーリング サブシステムを作成することを推奨しているわけではありません。ぜひ、お持ちのサブシステムを使用してください。ただし、スレッドの適切なカットオフ ポイントについて質問されていたので、スレッド プールの実装には、作成されるスレッドの最大数を制限する機能があると思います (これは良いことです)。

私はスレッドとデータベース接続のプール コードを作成しましたが、それらには次の機能があります (パフォーマンスには不可欠であると考えています)。

• アクティブなスレッドの最小数。
• スレッドの最大数。
• しばらく使用されていないスレッドをシャットダウンします。

最初の設定は、スレッド プール クライアントの観点で最小パフォーマンスのベースラインを設定します (このスレッド数は常に使用可能です)。2 番目の設定は、アクティブなスレッドによるリソースの使用に制限を設定します。3 番目の設定は、リソースの使用を最小限に抑えるために、静かな時間にベースラインに戻します。

未使用のスレッドによるリソース使用量 (A) と、作業を実行するための十分なスレッドがないことによるリソース使用量 (B) のバランスを取る必要があります。

(A) は通常、メモリ使用量 (スタックなど) です。何も作業していないスレッドは CPU をあまり使用しないからです。(B) は通常、スレッドが使用可能になるまで待つ必要があるため、リクエストが到着したときにその処理が遅れます。

だからこそ、測定するのです。おっしゃるとおり、スレッドの大部分はデータベースからの応答を待っているため、実行されません。許容すべきスレッドの数に影響する要因は 2 つあります。

1 つ目は、利用可能な DB 接続の数です。これは、DBMS で増やすことができない限り、ハード リミットになる可能性があります。この場合、DBMS は無制限の数の接続を受け入れることができると想定します (理想的には、それも測定する必要があります)。

次に、必要なスレッド数は、これまでの使用状況によって異なります。実行する必要がある最小数は、これまで実行していた最小数 + A% で、絶対最小値は (たとえば、A のように構成可能にする) 5 です。

スレッドの最大数は、過去の最大値 + B% にする必要があります。

動作の変化も監視する必要があります。何らかの理由で、使用率が長時間にわたって 100% に達した場合 (クライアントのパフォーマンスに影響するほど)、許容される最大値を再び B% 増加するまで引き上げる必要があります。

「具体的に何を測定すればよいのか？」という質問に対する回答:

具体的に測定すべきなのは、負荷がかかった状態で同時に使用されるスレッドの最大数 (例: DB 呼び出しからの戻りを待機中) です。次に、たとえば 10% の安全係数を追加します(他の投稿者は私の例を固定の推奨事項として受け取っているようなので強調します)。

さらに、チューニングのために本番環境でこれを行う必要があります。事前に見積もりを取得することは問題ありませんが、本番環境で何が起こるかはわかりません (そのため、これらすべてを実行時に構成可能にする必要があります)。これは、クライアント呼び出しが予期せず 2 倍になるなどの状況を把握するためです。