(轉)SQL Server內存遭遇操做系統進程壓榨案例

原文地址：http://www.cnblogs.com/zc_0101/p/3592259.html

場景：

　　最近一臺DB服務器偶爾出現CPU報警，個人郵件報警閾（請讀yù）值設置的是15%，開始時沒當回事，覺得是有什麼統計類的查詢，後來愈來愈頻繁。

探索：

　　我決定來查一下，到底是什麼在做怪，我排查的順序以下：

　　一、首先打開Cacti監控，發現最近CPU均值在某天以後驟然上升，而且能夠看到System\Processor Queue Length 和 sqlservr\%ProcessorTime 也在顯著的變化。

　　

　　二、從最容易入手的低效SQL開始，考慮是否是最近業務作了什麼修改？鏈接到該SQL實例，打開活動監視器，展開「最近耗費大量資源的查詢」，並CPU時間倒序，在這裏並未發現有即時的耗費資源的查詢。據我的經驗，這裏的值若是是4位數，分鐘內執行次數3位數，通常的服務器CPU大概就10%以上，若是cpu時間那裏是5位數，且分鐘內執行次數也很高，幾百次以上，那CPU通常就會不淡定了。圖片僅爲演示

　　

　　三、沒有耗資源的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! 這個案例告訴咱們，緩存命中率這個性能計數器不少時候說明不了什麼問題。

　　

　　四、OK，既然這樣，是誰佔用了本該屬於我親愛的SQL Server的內存呢？咱們繼續，打開Wiindows任務管理，選定進程選項卡，點擊顯示全部用戶進程，發現svchost.exe佔用了絕大多數的60G內存！

　　

　　五、那svchost.exe又是個什麼東西呢？咱們下面就用到ProcessMonitor這個工具了，打開後自動加載全部Wiindows進程，按內存排序後，鼠標移至svchost.exe進程上，顯示爲Remote Registry服務。

　　

　　六、查到這裏，事情已經有了必定的眉目，這個多半是windows內存泄露Bug，遂google關鍵詞: windows server 2008 r2 remote registry memory leak 

　　找到以下連接：http://support.microsoft.com/kb/2699780/en-us

　　果真：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.

解決方法：

　　一、重啓服務器，安裝hotfix

　　二、由於重啓服務器會影響到業務，因此我在想重啓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，微軟就笑了。有經驗的大夫應該從平常的腰痠背痛中看出一