SQL Server內存遭受操作體系過程壓搾案例剖析。本站提示廣大學習愛好者：（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，遂谷歌症結詞: 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的價值。這個案例，告知我，看重辦事器異常的細節變更，能力做到防患於已然。
