2014/3/12

SQL Server內存遭遇操作系統進程壓榨案例


From :http://blog.jobbole.com/62432/


原文出處: Czperfectaction的博客  


場景:

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

探索:

我決定來查一下,究竟是什麼在作怪,我排查的順序如下:
1、首先打開Cacti監控,發現最近CPU均值在某天之後驟然上升,並且可以看到System\Processor Queue Length 和 sqlservr\%ProcessorTime 也在顯著的變化。
egwegweg101627022872955
2、從最容易入手的低效SQL開始,考慮是不是最近業務做了什麼修改?連接到該SQL實例,打開活動監視器,展開「最近耗費大量資源的查詢」,並 CPU時間倒序,在這裡並未發現有即時的耗費資源的查詢。據個人經驗,這裡的值如果是4位數,分鐘內執行次數3位數,一般的服務器CPU大概就10%以 上,如果cpu時間那裡是5位數,且分鐘內執行次數也很高,幾百次以上,那CPU一般就會不淡定了。圖片僅為演示
regergehg101637470523676
ergegg101637579375581
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! 這個案例告訴我們,緩存命中率這個性能計數器很多時候說明不了什麼問題。
geg54545y54ygrg101644419859009
4、OK,既然這樣,是誰佔用了本該屬於我親愛的SQL Server的內存呢?我們繼續,打開Wiindows任務管理,選定進程選項卡,點擊顯示所有用戶進程,發現svchost.exe佔用了絕大多數的60G內存!
regregerg101701562239210
5、那svchost.exe又是個什麼東西呢?我們下面就用到ProcessMonitor這個工具了,打開後自動加載所有Wiindows進程,按內存排序後,鼠標移至svchost.exe進程上,顯示為Remote Registry服務。
trhrth1hgegh01704346942165
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也能指示病症已消除,我很欣慰。
rgreger101724207207725
regfwegfwgf101738120387322

總結:

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

JPA+complex key+custom Query

  來源: https://www.cnblogs.com/520playboy/p/6512592.html   整個來說,就是有複合主鍵 然後要使用  public interface XxXXxx DAO extends CrudRepository<Tc...