虛擬化 SQL Server 達到 100% CPU 和 0 活動記憶體
我們最近在我們的一台伺服器上經歷了一次奇怪的崩潰。我們知道是什麼原因造成的，但我們不知道為什麼 SQL Server 會以這種方式響應。
SQL 伺服器 2016
這是發生的事情：
星期五：將 MAXDOP 從 4 更改為 2，但未檢查這會對編譯查詢產生多大影響。
星期六早上：伺服器從凌晨 2 點開始逐漸使用更多 CPU，直到凌晨 5 點達到 100%，並且活動 RAM 立即從 44GB 下降到 500MB（什麼？！？！）。伺服器重新啟動，一切正常。
星期一早上：凌晨 1:05，當一個夜間批處理作業開始時，伺服器達到 100% CPU 並在凌晨 1:15 將活動記憶體降至 500 MB。
作為我們夜間批處理的一部分，每天早上都會在此伺服器上執行大量大型查詢。查看查詢儲存，我可以看到它們都是在周五更改為 MDOP 之前為 4 個核心編譯的。
因此，過去有 4 個核心的所有大型查詢都必須為 2 個核心重新編譯，這使得在該伺服器最繁忙的時間框架之一期間所有這些查詢都變慢了。我了解這將如何顯著影響伺服器的性能，但我不明白為什麼伺服器變得完全沒有響應，並且活動記憶體如此之少。
有沒有人對這種行為有一些經驗？
查看 David Klee 的這篇有趣的文章：VM 記憶體計數器對 SQL Server 虛擬機的謊言
特別是，這句話與您的情況非常相關：
SQL Server 使用記憶體作為工作集 I/O 緩衝區，SQL Server 緩衝池中的記憶體塊最常用作讀取記憶體。只有在最後一個採樣間隔（通常為 20 秒）內讀取或寫入該塊時，重複讀取的記憶體塊才會顯示在活動計數器中。因此，分配給 VM 的記憶體量適當（或過高，但那是另一回事）的 SQL Server 將在記憶體中擁有大部分經常訪問的數據，但這些塊很少被完整地訪問。一個範例視窗。VM 活動記憶體計數器將顯示非常低的活動值，但此 SQL Server 實際上可能非常繁忙。
這解釋了您的第一個問題（與“活動”記憶體有關）。從本質上講，您所查看的指標並不可靠，因此它並不能告訴我們有關情況的太多實質內容。
另一個與無響應有關的問題，如果不查看中斷時的等待統計資訊或重新編譯的執行計劃的細節，就很難確定。
如果我要推測，一個合理的理論可能是：
- 現在以 MAXDOP 2（而不是 4）執行的查詢需要更長的時間才能完成
- 查詢以與以前相同的速度到達伺服器
- 所以現在有更多的查詢同時執行（因為它們需要更長的時間才能完成）
- 伺服器開始出現執行緒不足（執行緒池等待），因為有太多並發查詢正在執行
- 如果查詢需要記憶體授權，它們也可以開始排隊等待記憶體（resource_semaphore 等待）
所有這些事情都會結合起來使您的伺服器看起來沒有響應。它還可能導致 VM 中的“活動記憶體”下降，因為記憶體頁面的訪問量可能會減少（由於所有內容都在等待 CPU 資源）。