Expert 診斷優化系列------------------內存不夠用麼？

　　　　如今不少用戶被數據庫的慢的問題所困擾，又苦於花錢請一個專業的DBA成本過高。軟件維護人員對數據庫的瞭解又不是那麼深刻，因此致使問題遲遲不能解決，或只能暫時解決不能獲得根治。開發人員解決數據問題基本又是搜遍百度各類方法嘗試個遍，可能錯過診斷問題的最佳時機又可能嘗試一堆方法最後無奈放棄。

　　　　怎麼樣讓雜事纏身的程序維護人員，用最快的方式解決數據庫出現的問題？怎麼讓咱們程序員的痛苦下降到最小...天天喝喝茶水，看看新聞平安度過一天呢？本系列重要經過Expert for sqlserver 工具講解下數據庫遇到的各類問題的表象及致使這樣問題的根本緣由，讓定位問題更準確，解決問題思路更清晰！！

　　　　數據庫的性能好壞，對於最終用戶來講表現爲點擊的操做是否可以快速響應，那麼反應到數據庫上就是語句執行時間是否夠短！

　　　　對用運維人員數據庫性能的表現，簡單可能當作CPU 、內存、磁盤三巨頭指標是否正常，上一篇講述了CPU的基本診斷

Expert 診斷優化系列------------------你的CPU高麼？

　　　　本篇咱們就從內存下手，看看內存可以看出哪些問題！

廢話很少說，直接開整-----------------------------------------------------------------------------------------

　　　　首先說明一個誤區，你是否被這樣的畫面所震驚？

　　　　

 

　　　　個人服務器內存滿了，就是這個致使我數據庫慢！個人程序報錯也是由於這個，什麼都由於內存滿了！！　　趕忙加內存吧~ 

　　　　這個答案是大寫的 「不必定」，SQL SERVER是一個很愛內存的傢伙，他會緩存你的數據，執行計劃，鏈接信息等等，因此出現這個現象是很正常的，不要輕易下結論，除非你通過仔細的研究和分析！

　　　　那麼怎麼去分析究竟是不是內存不足致使的問題呢？　　下面咱們來講說！

主要用到的性能計數器（不知道什麼是性能計數器的，請自行百度）

1. Page life expectancy （數據庫計數器：主要顯示不被使用的頁，將在緩存中停留的秒數 ）
2. Lazy writes/sec　　（數據庫計數器：惰性寫入器會在內存有壓力且有新的內存需求時觸發，成批的刷新「老化的緩衝區」）
3. Page Reads/sec，Page Writes/sec　　（這裏使用數據庫級別計數器：當須要讀取或寫入的頁不在內存中，須要到磁盤中讀取時計數）
4. Target Server Memory (KB)  （SQL server可以使用的內存總量）
5. Total Server Memory (KB)　　（SQL SERVER使用的內存總量，這裏指BUFFER POOL的大小）
6. Available MBytes　 （系統係數器：主要顯示系統還有多少可用內存）

　　注：Target Server Memory (KB) - Total Server Memory (KB) 約等於SQL SERVER還可使用的內存數。

 

　　Available MBytes 主要顯示系統中還多少空閒內存 （若是這個值較大，而SQL SERVER還可使用的內存數爲0或者較小，能夠適當的調大max server memory（最大內存，稍後介紹））

　　　　

　　　這裏再也不細說這三個計數器，咱們主要經過前三個計數的聯動來判斷系統的內存是否真的存在壓力！！！

　　　首先介紹一下，這三個計數器是如何聯動的？

　　　概念出發：Page life expectancy 不被使用的頁在緩存中停留的秒數，若是低說明內存壓力

　　　　　　　　Page Reads/sec　所要讀的數據不在內存中須要物理讀取

　　　　　　　　Lazy writes/sec　內存壓力時成批的刷新老化緩衝區　

　　　當一個操做須要大量讀取數據，且數據頁不在緩存中 ——》 那麼須要大量從磁盤讀取冷數據放入緩存（Page Reads/sec 升高） ——》緩存有明顯壓力的時候Lazy writes/sec就會觸發（Lazy writes/sec升高），大批量的將老化的數據或緩存計劃等刷出緩存 ——》數據被清出緩存，那麼頁生命週期就會降低（Page life expectancy）

　　　　

　　　　Page Reads/sec

　　　　

　　　　Lazy writes/sec

　　　　

　　　　Page life expectancy

　　　　

 

 

　　　　高能預警：當你看到本身的計數器是這個樣子的時候，你給的出結論不該該單單是，我內存有壓力！

　　　　這個例子不光爲了說明三計數器是聯動，並且也能夠看出規律，那就是每三小時一次明顯的內存壓力。正如第一篇CPU文章的介紹，這種規律性的表象，做爲系統的維護人員，必定要仔細想一想什麼操做致使的問題？不要由於一個簡單的配置問題而拖慢了整個系統！

　　　　我經過對問題時間點的語句分析發現，這個系統每三小時進行一第二天志備份，正常的日誌備份不會致使這樣的現象，但若是在日誌備份的時候加上CHECKDB呢？

　　　　這就是所說的不要由於一個小的失誤而影響整個系統！

 

--------------------------------------------------------------------------------------------

系統內存不足的表象　　　　　　　　　　

　　　　下面展現一個內存壓力的服務器這三個計數器的表象：

　　　　Page Reads/sec

　　　　

　　　　Lazy writes/sec　　　　

　　　　

　　　　Page life expectancy 頁生命週期

　　　　

 

　　　　　

　　　　這幾個計數器反應出的問題絕對是系統內存嚴重不足，計數器雙高一低。那麼當咱們知道系統內存不足的時候應該怎麼辦呢？加內存麼？

　　　　不要急，下面咱們說說如何讓你的系統節省內存，也許作過這一輪優化，你的系統內存就夠用了！ 你沒聽錯，就是-----優化！

 

優化-----讓你的內存無壓力

 

　　　　你要給你的系統設置最大內存max server memory　　　

　　　　

 

 

　　　　問：我係統內存原本就不夠爲何還要設置使用上限？我這服務器就給數據庫用還用設置？

　　　答：數據庫是運行在windows 上的應用，他和notepad對於操做系統來講本質上沒區別，那麼這就比如君（操做系統）與 臣（數據庫）的關係。

　　　　而SQL SERVER是一個很喜歡內存的應用，因此極可能吃掉大量內存致使windows系統沒有足夠內存使用，，那麼這時候君臣關係就體現的淋漓盡致了，君(windows) 要臣（SQL SERVER）死（釋放內存）臣不得不死呀...這個釋放在必定程度上可不是單單讓windows夠用了，極可能致使SQL內存陡降，以至SQL 短期假死（操做無響應）。因此爲了你數據庫的穩定性，這個最大上限必定要設置。

 

　　　　內存設置推薦：

　　　　通常我比較推薦若是內存較小操做系統預留3G-4G ，若是內存大256或512以上在數據庫內存無壓力時預留5%給操做系統，剩下給SQL SERVER ，若是服務器還有其餘應用還要在SQL 中減掉應用所佔的內存。

　　　　若是內存比較小且數據庫內存壓力大，則能夠經過前面講述的Available MBytes 的判斷結果適量給系統預留內存。

 

　　　　

　　　　注意：最大內存的設置單位爲 MB

 

語句的優化，讓語句消耗內存更少！

　　　　語句優化系列請關注後續文章，這裏只針對下降內存

　　　　下降內存對語句優化主要集中在幾個方面：

1. 是否缺失索引？ 
2. 消耗內存的操做是否能夠消除（如排序）
3. 下降語句複雜性，讓優化器能選用最佳計劃

 

　　　　語句消耗內存主要體如今大量的讀取，或者有排序等操做。限於篇幅這裏只作簡單的例子，詳細的語句優化請關注後續文章。

　　　　所謂的讀，寫簡單理解就是在語句執行時所須要用到的數據頁數，須要的越多就須要越大的內存來緩存這些數據頁。若是須要的頁不在內存中還須要從磁盤讀取 （磁盤讀取就是爲何Page Reads/sec 會高）

　　　　

 

　　　　簡單的一個加索引下降邏輯讀的例子~

　　　　

 

　　　　

　　　　

　　　　語句使用了一個整個表掃描的計劃，執行了 19秒，邏輯讀取143800次，預讀137236 （磁盤上讀取），消耗了40KB 的內存 ，而且明確提示出缺乏索引！

　　　　那麼咱們加上提示缺乏的索引，再次執行

　　　　

　　　　

 

　　　　加上索引的語句執行不到1秒 邏輯讀下降到13次，內存消耗已經能夠忽略不計。這就是索引對語句的重要性！單條語句如此，你的系統中到底有多少這樣的語句呢？

　　　　

 

 

　　　　再來看一個寫法修改的例子 ：

　　　　

　　　　

　　　　

 

 

　　　　只是簡單的改了下語句的寫法時間有7秒變成1秒，內存消耗從300+MB 變成 1MB

　　　　

　　　　這兩個例子，告訴咱們也許系統中簡簡單單作一些調整，內存的壓力就會明顯下降或者變得很是充足，因此在你下了一個須要購買內存的決定前，是否針對系統的語句進行過調優？

　　　　　　

-----------------------------------------------------------------------------------------------------

 

 對於內存性能計數器的閥值簡單說明

 

 Page life expectancy 計數器這個時間要高於多少纔算正常呢？

　　　　答：不少資料上多這個值都有誤解，說是300S，300S是在十多年前的一個參考值，是基於當時的服務器內存受到4GB內存的限制的影響獲得的，

　　目前服務器內存動輒超過100GB的狀況下，用一樣的標準，顯然是不夠準確的，這個值的計算是跟具體的服務器內存配置有關的，一個可供參考的標準算法是 Max Buffer Pool(GB)/4*300(S)

 

 

 

爲何這裏缺乏了一個 Buffer Cache hit ratio 計數器？

不少材料上都介紹其閾值是90%，95%之類的參考值，其實都是錯誤的，

　　　　其實真正觀察過的人，早就會發現，從PLE和Buffer hit ratio得出根本不一致的結論。

 

詳細說明請參見：wy123的博客

Sql Server 內存相關計數器以及內存壓力診斷

Buffer cache hit ratio性能計數器真的能夠做爲內存瓶頸的判斷指標嗎？

 

 

 

 -----------------------------------------------------------------------------------------------------

　　總結：內存對於數據庫來講是最爲重要的依賴之一，內存的問題診斷和優化對系統相當重要。

　　　　　優化語句可讓你的系統內存壓力明顯下降。

　　　　　語句優化所帶來的效果，在很大程度上會比添加硬件更有效！

　　　　　做爲一個技術人員對於系統問題的定位、分析、調優是最重要的，若是內存問題都經過加內存來解決，咱們的價值何在呢？

 

 

 

 ----------------------------------------------------------------------------------------------------

注：此文章爲原創，歡迎轉載，請在文章頁面明顯位置給出此文連接！
若您以爲這篇文章還不錯請點擊下右下角的推薦，很是感謝！

　　引用高大俠的一句話 ：「拒絕SQL Server背鍋，從我作起!」

爲了方便閱讀給出系列文章的導讀連接：

SQL SERVER全面優化-------Expert for SQL Server 診斷系列