場(chǎng)景：

最近一臺(tái)DB服務(wù)器偶爾出現(xiàn)CPU報(bào)警，我的郵件報(bào)警閾（請(qǐng)讀yù）值設(shè)置的是15%，開始時(shí)沒當(dāng)回事，以為是有什么統(tǒng)計(jì)類的查詢，后來越來越頻繁。

探索：

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

1、首先打開Cacti監(jiān)控，發(fā)現(xiàn)最近CPU均值在某天之后驟然上升，并且可以看到System\Processor Queue Length 和 sqlservr\%ProcessorTime 也在顯著的變化。

2、從最容易入手的低效SQL開始，考慮是不是最近業(yè)務(wù)做了什么修改？連接到該SQL實(shí)例，打開活動(dòng)監(jiān)視器，展開“最近耗費(fèi)大量資源的查詢”，并CPU時(shí)間倒序，在這里并未發(fā)現(xiàn)有即時(shí)的耗費(fèi)資源的查詢。據(jù)個(gè)人經(jīng)驗(yàn)，這里的值如果是4位數(shù)，分鐘內(nèi)執(zhí)行次數(shù)3位數(shù)，一般的服務(wù)器CPU大概就10%以上，如果cpu時(shí)間那里是5位數(shù)，且分鐘內(nèi)執(zhí)行次數(shù)也很高，幾百次以上，那CPU一般就會(huì)不淡定了。圖片僅為演示：

3、沒有耗資源的SQL，這是DBA最不愿意看到的結(jié)果，因?yàn)橐苍S，SQL Server受到了來自內(nèi)部或者外部的壓力，使得自己花費(fèi)了過多的時(shí)間去處理與操作系統(tǒng)的溝通去了。SQL Server常見的非查詢低效類的性能問題，絕大多數(shù)都來自于內(nèi)存或者硬盤，而這兩者有的時(shí)候需要同時(shí)研究對(duì)比基線，才能確定誰是因，誰是果。在這里，我們首先查看SQL Server內(nèi)存使用情況，當(dāng)打開性能計(jì)數(shù)器時(shí)，我和我的小伙伴們都驚呆了……安裝了64G內(nèi)存的數(shù)據(jù)庫(kù)，SQL Server的TargetMemory僅有500多兆！這其中StolenPage還占用了200多兆，數(shù)據(jù)庫(kù)DataPage僅有200多兆的內(nèi)存可供使用，Oh，Shit！雖然我很不想用“去哪了”這三個(gè)字，但是“我的內(nèi)存去哪了“？同時(shí)我們也注意到PageLifeExpectancy值只有26（一個(gè)內(nèi)存充足的服務(wù)器，這個(gè)值至少應(yīng)該是上W的），而很早之前我們津津樂道的”Cache Hit Ration”卻仍然保持一個(gè)比較高的水準(zhǔn)98! 這個(gè)案例告訴我們，緩存命中率這個(gè)性能計(jì)數(shù)器很多時(shí)候說明不了什么問題。

4、OK，既然這樣，是誰占用了本該屬于我親愛的SQL Server的內(nèi)存呢？我們繼續(xù)，打開Wiindows任務(wù)管理，選定進(jìn)程選項(xiàng)卡，點(diǎn)擊顯示所有用戶進(jìn)程，發(fā)現(xiàn)svchost.exe占用了絕大多數(shù)的60G內(nèi)存！

5、那svchost.exe又是個(gè)什么東西呢？我們下面就用到ProcessMonitor這個(gè)工具了，打開后自動(dòng)加載所有Wiindows進(jìn)程，按內(nèi)存排序后，鼠標(biāo)移至svchost.exe進(jìn)程上，顯示為Remote Registry服務(wù)。

6、查到這里，事情已經(jīng)有了一定的眉目，這個(gè)多半是windows內(nèi)存泄露Bug，遂google關(guān)鍵詞: 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.

解決方法：

1、重啟服務(wù)器，安裝hotfix

2、因?yàn)橹貑⒎?wù)器會(huì)影響到業(yè)務(wù)，所以我在想重啟RemoteRegistry服務(wù)，應(yīng)該也能暫時(shí)解決問題，這個(gè)bug應(yīng)該是在某種固定情景下發(fā)生的。

隨后，在合適的時(shí)間，我重啟了這個(gè)服務(wù)，SQL Server的TargetMemory重新恢復(fù)到60多G，CPU也正常了，目前為止該問題未再發(fā)生。

后續(xù)跟進(jìn)：

DBA的工作，說難也難，說容易也容易，發(fā)現(xiàn)問題，解決問題還不夠，我們還要意識(shí)到自己的欠缺，在本案例中，我之前并沒有建立起SQL Server內(nèi)存的監(jiān)控，所以沒有在***時(shí)間就發(fā)現(xiàn)病情的嚴(yán)重性，好在該服務(wù)器并未承擔(dān)重要業(yè)務(wù)，否則后果不堪設(shè)想，說不定早就崩潰過了，后怕之處在于，如果崩潰了，自然要重啟服務(wù)器，到那個(gè)時(shí)候，我們連***現(xiàn)場(chǎng)都沒有，當(dāng)leader問起來，我又該使勁撓頭了。

該事件之后，我建立起了SQL Server內(nèi)存的監(jiān)控，1天后，我從新的監(jiān)控?cái)?shù)據(jù)中，又發(fā)現(xiàn)了一臺(tái)服務(wù)器出現(xiàn)相同的問題！我很慶幸，不是慶幸服務(wù)器沒宕機(jī)，而是慶幸我做對(duì)了。

附一張內(nèi)存監(jiān)控圖，可以看到服務(wù)重啟之后，SQL Server的Total Pages一直在上升，并逐漸穩(wěn)定,Page life expectancy也在變得越來越大，CPU也能指示病癥已消除，我很欣慰。

總結(jié)：

服務(wù)器在出現(xiàn)性能問題前，大部分是提前有一些征兆的，尤其是內(nèi)存泄露，因?yàn)閮?nèi)存是一點(diǎn)點(diǎn)被壓榨掉的，***到達(dá)一個(gè)極限時(shí)，SQL Server就會(huì)突然Crash掉，然后只留給你一個(gè)dump，微軟就笑了。有經(jīng)驗(yàn)的大夫應(yīng)該從日常的腰酸背痛中看出一些端倪，然后進(jìn)一步分析，提前預(yù)知重大疾病的發(fā)生，這就是DBA的價(jià)值。這個(gè)案例，告訴我，重視服務(wù)器異常的細(xì)節(jié)變化，才能做到防患于未然。