これらのことは、徹底的に分析して適切な提案を行うために、コードの綿密な検査と可用性を明らかに必要とします。それでも、それが常に可能であるとは限らず、以下に提供する情報に基づいて、良いヒントを提供できることを願っています。
リスナースレッドを使用して着信データをリッスンするサーバーアプリケーションがあります。着信データはアプリケーション固有のメッセージに解釈され、これらのメッセージによってイベントが発生します。
その時点まで、私は物事がどのように行われるかを実際に制御することはできません。
これはレガシーアプリケーションであるため、これらのイベントは以前は同じリスナースレッド（主にシングルスレッドアプリケーション）によって処理されていました。イベントはブラックボックスに送信され、ディスクに書き込む必要のある結果が出力されます。
スループットを向上させるために、イベントを処理するためにスレッドプールを採用したいと思いました。リスナースレッドは、イベントが作成されるたびに新しいタスクを生成でき、スレッドがブラックボックスの呼び出しを処理するという考え方です。最後に、ディスクへの書き込みを実行するバックグラウンドスレッドがあります。
以前のセットアップとバックグラウンドライターだけで、すべてが正常に機能し、スループットは以前の約1.6倍になります。
ただし、スレッドプールを追加すると、パフォーマンスが低下します。最初はすべてがスムーズに実行されているように見えますが、しばらくするとすべてが非常に遅くなり、最終的にOutOfMemoryExceptionsが発生します。奇妙なことに、タスクがプールに追加されるたびにアクティブなスレッドの数を出力すると（キューに入れられているタスクの数などの情報とともに）、スレッドプールが問題なく対応しているように見えます。プロデューサー（リスナースレッド）。
top -Hを使用してCPU使用率をチェックすると、最初は非常に均等に分散されますが、最終的にはワーカースレッドがほとんどアクティブにならず、リスナースレッドのみがアクティブになります。それでも、それ以上のタスクを送信していないようです...
誰かがこれらの症状の理由を推測できますか？複数のスレッドが追加されたときに、レガシーコード（私が制御できないもの）に何かがうまくいかない可能性が高いと思いますか？メモリ不足の問題は、どこかのキューが大きくなりすぎたために発生するはずですが、スレッドプールにキューに入れられたタスクが含まれることはほとんどないため、それは不可能です。
どんなアイデアでも大歓迎です。特に、このような状況をより効率的に診断する方法のアイデア。スレッドが実行していることなどについて、より良いプロファイルを取得するにはどうすればよいですか。
ありがとう。
