好的，我們的新版本在每台伺服器上以隨機間隔出現 100% 的 CPU 峰值。在很長一段時間內，它會使網站完全沒有響應 - 這將在高峰時段，因為不同國家的人們登錄該網站等。
我們研究了 perfmom、記憶體分析器、CLR 分析器、sql 分析器、紅門螞蟻分析器，嘗試在 UAT 中進行負載測試 - 但甚至無法重現問題。這可能意味著只有數千名用戶造訪即時網站才會導致這種情況發生。
我們確實注意到的一種模式是，新程式碼（損壞的建置）實際上使用了明顯更少的執行緒。
我們也在 IOC 中使用彈簧 - 這有床聲譽嗎？
更糟的是，由於業務影響，我們無法部署上線 - 因此無法將問題縮小到我們新增的功能的子集。
我們真的被摧毀了——有誰留下任何戰鬥傷疤可以挽救我們的生命嗎？
答案1
我建議使用 Sos 進行記憶體轉儲並在 WinDdg 中分析它們。我修復了生產中的一些問題，如果沒有 WinDbg，我可能無法診斷。
苔絲·費爾南德斯有很棒的博客，您可以在其中學習如何分析內存轉儲。
答案2
這通常是由 GC 中的大型長壽命物件清理引起的（stackoverflow 有這個問題，請參閱鏈接）。您是否在快取或會話中儲存大量物件集合？
我還建議您在生產中建置並配置一個新伺服器以進行測試。如果你有隨機的瘋狂並且不知道為什麼並且無法重現它，我會把矛頭指向硬體或配置，而不是代碼。
答案3
這是共享資源的虛擬伺服器還是實體伺服器？如果是前者，也許您可以考慮將資源專用於該伺服器。祝你好運...
答案4
在沒有數據的情況下試圖猜測故障是沒有意義的。是的，stackoverflow 上或你的工程團隊中的某個人可能會很幸運，但這只是糟糕的工程，你無法制定一個計劃來確定嘗試每一個猜測需要多長時間，以及你是否會發現問題。
- 你必須重現問題。 Jmeter 因其廣度而成為一個良好的開端，但在不了解我們的架構的情況下，我們無法推薦正確的工具。
- 記錄特別是在你的應用程式層是必須的。您可以啟用 IIS 追蹤來降低效能，但 Microsoft 的傀儡卻做到了這一點，因此您無法在速度緩慢時擷取整個管道流。如果重現如此困難，您真的需要一些日誌來幫助您縮小範圍在哪裡問題是。 （就像哦，每當我們呼叫這個預存程序時）。
100% CPU 有點可疑，因為它不太可能是 I/O（假設資料庫是另一個盒子，緩慢的資料庫不應導致網頁伺服器上的 100% CPU）。你需要離家更近。