VM イメージでパフォーマンスの問題が発生しています (VM ホストにはアクセスできず、ゲスト OS のみにアクセス可能です)。
サーバーがリクエストの送信を停止する期間が 10 〜 60 秒ある理由を特定しようとしています。
これを実行する際に、いくつかのパフォーマンス カウンターを実行しましたが、非常に奇妙なことに気付きました。これらの「デッド」期間が始まってすぐに、すべての ASP.NET アプリケーション カウンター (アクティブなセッション、パイプライン インスタンス数、実行中の要求) がゼロに下がり、「デッド」期間を抜けるとすぐに通常のレベルに戻ります。次のグラフを参照してください。
これらのセッションは、カウンター統計からは削除されたものの、期間全体を通じて引き続き実行されていたことは 100% 確実です。
これまでにカウンターのこの動作を見た人はいますか? 何らかの VM リソース不足が原因で、これらのカウンターが誤動作し、デッド期間が全体的に発生している可能性はありますか?
答え1
ちょうどこの問題があり、私は気が狂いそうになり、他にもたくさんの問題を引き起こしていました。その最悪の状況では、リクエストが停止したりBeginRequest、MapRequestHandler10 秒以上経ってから突然、再び状態が進行し始めたりしていました。
根本的な原因は、IIS アプリが自身の /bin ディレクトリ内にファイルを書き込んでいたことにありました。IIS はそれを検出し、ソフト リサイクルを発行して、リスニング ワーカーの数を一時的に 0 に減らしました (Pipeline Instance Countこの質問を見つけた理由と、それに示されています)。ただし、これは他のツールでは新しいプロセスなどとして表示されませんでした。
すべてのIISプロセスのミニダンプを取得して、これを発見しました。デバッグ診断2速度低下の 1 つ中に MS から、fiddler を使用して小さなエンドポイントを ping して発見されました。DebugDiag には CrashHangAnalysis レポートがあります。そのレポートには多くの情報が含まれていました。およびHttpRuntime Shutdown Reportを含むスタック トレースでを見つけるのにしばらく時間がかかりました。System.Web.DirectoryMonitor.FireNotificationsSystem.Web.Compilation.BuildManager.OnWebHashFileChange
それで、prod bin ディレクトリを調べてみたところ、そこに誤ったメール ログが書き込まれていて、IIS がアプリをリサイクルしていることがわかりました。これは特に奇妙でした。New Relic のアプリのメモリ グラフには、安定したメモリ リークのように見えるものが表示されていたのに、実際にはアプリ全体が (ある意味) 再起動して、既存のメモリを増やしていたからです。通常のリサイクルのようには見えず、PID は同じままでした。IIS が何をしようとしていたのか、まったくわかりません。
また、IIS AppPoolの詳細設定を次のようDisable Recycling for Configuration Changesに変更しても、この問題は回避できませんでした。Trueこの他の質問これを修正するには、バイナリを変更して再デプロイする必要がありました。