2016-08-18 1 views
0

私はこのように動作するIISアプリケーションを持っています - IISプロセスの総スレッド数が少なく、5rpmのような低速でトラフィックが始まり、スレッド数が増加し始め、負荷が停止した後、合理的な時間に降下せず、30,000プラススレッドに達すると、応答時間はトスになります。IIS高いスレッド数

マシン構成がauto_Configに設定されています。

アプリケーションには明示的なスレッドはありませんが、非常にファンシーなものがあります。

これを診断するにはどうすればよいですか?それぞれを並列化することは助けに見えた。私はまだそれを決定的に証明することはできません。スレッドの最大数を制限することも、スレッド数を制限するのに役立ちます。私はそれらのスレッドが増加を続けさせる原因となるアプリに何か問題があると考えています。私はこれを解決したいと思います。

下の図のスレッドカウントは、IISワーカープロセスの場合のみです。 PUTリクエストは仕事をする唯一のものです。取得は主に静的リソース要求です。

enter image description here

+0

スクリーンショットにはどの監視ツールがありますか? – serhiyb

+0

DataDog監視ツール。私は、TaskManager/Resource Monitorのスレッド数も確認しました。 – Amit

+0

このようなデータは原因を特定するのに役に立たず、正確な症状を示すのに役立ちます。パフォーマンスプロファイラを実行できる場合は、各スレッドの処理状況を追跡し、原因を突き止めることができます。そうでない場合、ハングダンプ解析が役立ちます。このような問題には簡単な答えはありません。 –

答えて

0

これは、ローカルまたはDEV環境で再現することはできますか?もしそうなら、プロセスに接続し、デバッグツールを使用して、どのスレッドが管理されているのか、どこにコードがあるのか​​を確認することができます。それが何かを明らかにしなければ、プロセスからメモリダンプを取り込み、windbgでそれを掘り下げる時間があるかもしれません。

関連する問題