程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> 其他數據庫知識 >> 更多數據庫知識 >> SQL Server內存遭遇操作系統進程壓搾案例分析

SQL Server內存遭遇操作系統進程壓搾案例分析

編輯:更多數據庫知識

場景:

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

探索:

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

  1、首先打開Cacti監控,發現最近CPU均值在某天之後驟然上升,並且可以看到System\Processor 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 

  找到如下鏈接: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、重啟服務器,安裝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的價值。這個案例,告訴我,重視服務器異常的細節變化,才能做到防患於未然。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved