SQL Server記憶體遭遇作業系統進程壓榨案例

 　　來源於點擊開啟連結

　　情境：

　　最近一台DB伺服器偶爾出現CPU警示，我的郵件警示閾(請讀yù)值設定的是15%，開始時沒當回事，以為是有什麼統計類的查詢，後來越來越頻繁。

　　探索：

　　我決定來查一下，究竟是什麼在作怪，我排查的順序如下：

　　1、首先開啟Cacti監控，發現最近CPU均值在某天之後驟然上升，並且可以看到SystemProcessor Queue Length 和 sqlservr%ProcessorTime 也在顯著的變化。

　　2、從最容易入手的低效SQL開始，考慮是不是最近業務做了什麼修改?串連到該SQL執行個體，開啟活動監視器，展開“最近耗費大量資源的查詢”，並CPU時間倒序，在這裡並未發現有即時的耗費資源的查詢。據個人經驗，這裡的值如果是4位元，分鐘內執行次數3位元，一般的伺服器CPU大概就10%以上，如果cpu時間那裡是5位元，且分鐘內執行次數也很高，幾百次以上，那CPU一般就會不淡定了。圖片僅為示範

　　3、沒有耗資源的SQL，這是DBA最不願意看到的結果，因為也許，SQL Server受到了來自內部或者外部的壓力，使得自己花費了過多的時間去處理與作業系統的溝通去了。SQL Server常見的非查詢低效類的效能問題，絕大多數都來自於記憶體或者硬碟，而這兩者有的時候需要同時研究對比基準，才能確定誰是因，誰是果。在這裡，我們首先查看SQL Server記憶體使用量情況，當開啟效能計數器時，我和我的小夥伴們都驚呆了……安裝了64G記憶體的資料庫，SQL Server的TargetMemory僅有500多兆!這其中StolenPage還佔用了200多兆，資料庫DataPage僅有200多兆的記憶體可供使用，Oh，Shit!雖然我很不想用“去哪了”這三個字，但是“我的記憶體去哪了“?同時我們也注意到PageLifeExpectancy值只有26(一個記憶體充足的伺服器，這個值至少應該是上W的)，而很早之前我們津津樂道的"Cache Hit Ration"卻仍然保持一個比較高的水準98! 這個案例告訴我們，快取命中率這個效能計數器很多時候說明不了什麼問題。

　　4、OK，既然這樣，是誰佔用了本該屬於我親愛的SQL Server的記憶體呢?我們繼續，開啟Wiindows任務管理，選定進程選項卡，點擊顯示所有使用者進程，發現svchost.exe佔用了絕大多數的60G記憶體!

　　5、那svchost.exe又是個什麼東西呢?我們下面就用到ProcessMonitor這個工具了，開啟後自動載入所有Wiindows進程，按記憶體排序後，滑鼠移至svchost.exe進程上，顯示為Remote Registry服務。

　　6、查到這裡，事情已經有了一定的眉目，這個多半是windows記憶體泄露Bug，遂google關鍵詞: windows server 2008 r2 remote registry memory leak

　　果然：Assume that you query performance counters on a remote computer by using an application on a computer that is running Windows 7 or Windows Server 2008 R2. In this situation, the memory usage of the Remote 　　　Registry service on the local computer increases until the available memory is exhausted.

　　解決方案：

　　1、重啟伺服器，安裝hotfix

　　2、因為重啟伺服器會影響到業務，所以我在想重啟RemoteRegistry服務，應該也能暫時解決問題，這個bug應該是在某種固定情景下發生的。

　　隨後，在合適的時間，我重啟了這個服務，SQL Server的TargetMemory重新恢複到60多G，CPU也正常了，目前為止該問題未再發生。

　　後續跟進：

　　DBA的工作，說難也難，說容易也容易，發現問題，解決問題還不夠，我們還要意識到自己的欠缺，在本案例中，我之前並沒有建立起SQL Server記憶體的監控，所以沒有在第一時間就發現病情的嚴重性，好在該伺服器並未承擔重要業務，否則後果不堪設想，說不定早就崩潰過了，後怕之處在於，如果崩潰了，自然要重啟伺服器，到那個時候，我們連第一現場都沒有，當leader問起來，我又該使勁撓頭了。

　　該事件之後，我建立起了SQL Server記憶體的監控，1天后，我從新的監控資料中，又發現了一台伺服器出現相同的問題!我很慶幸，不是慶幸伺服器沒宕機，而是慶幸我做對了。

　　附一張記憶體監控圖，可以看到服務重啟之後，SQL Server的Total Pages一直在上升，並逐漸穩定,Page life expectancy也在變得越來越大，CPU也能指示病症已消除，我很欣慰。

　　總結：

　　伺服器在出現效能問題前，大部分是提前有一些徵兆的，尤其是記憶體泄露，因為記憶體是一點點被壓榨掉的，最後到達一個極限時，SQL Server就會突然Crash掉，然後只留給你一個dump，微軟就笑了。有經驗的大夫應該從日常的腰酸背痛中看出一些端倪，然後進一步分析，提前預知重大疾病的發生，這就是DBA的價值。這個案例，告訴我，重視伺服器異常的細節變化，才能做到防患於未然。