VM 映像存在一些效能問題（我無法存取 VM 主機，只能存取來賓作業系統）。
嘗試確定為什麼伺服器會在 10-60 秒的時間內停止推送任何請求。
在執行此操作時，我有幾個效能計數器，但我注意到一些非常奇怪的事情，在這些「死」期開始後不久，我的所有ASP.NET 應用程式計數器（活動會話、管道實例計數、執行請求）下降到零，然後開始射擊一旦我們擺脫“死亡”期，就會恢復到正常水平。請參閱此處的圖表：
我百分之百確定這些會話即使從計數器統計資料中刪除，在整個時間段內仍然正常運作。
有人以前在櫃檯看過這種行為嗎？是否有可能是某種虛擬機器資源匱乏導致這些計數器行為異常，並且可能導致一般的死區？
答案1
我們剛剛遇到了這個問題——讓我抓狂並引發了很多其他問題。在這個低點期間，請求會停滯BeginRequest或MapRequestHandler- 然後它們會在 10 多秒後突然開始再次進入狀態。
最終的根本原因是 IIS 應用程式正在自己的 /bin 目錄中寫入檔案。 IIS 偵測到它並發出軟回收，暫時將偵聽工作執行緒的數量減少到 0（如圖所示Pipeline Instance Count以及我發現此問題的原因）。然而，這並沒有在任何其他工具中顯示為新流程或類似流程。
我們透過使用以下命令對所有 IIS 進程進行小型轉儲來發現它調試診斷2在其中一次減速期間，來自 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不能防止此問題，如建議的那樣這另一個問題。我們必須更改並重新部署二進位檔案來修復它。