一個真實案例，教會你數(shù)據(jù)庫性能調(diào)優(yōu)
前言
微軟工程師的一個工程師曾經(jīng)對性能調(diào)優(yōu)有一個非常形象的比喻：剝洋蔥 。我也非常認可，讓我們來一層一層撥開外面它神秘的面紗。
六大因素
下面祭出的是我們在給客戶分析數(shù)據(jù)庫性能問題最常用的圖。
看完這個圖，你是不是對性能調(diào)優(yōu)有了個基本的概念了。通常來講，我們會依照下面的順序來進行分析：
-
硬件能力
-
系統(tǒng)規(guī)模
-
數(shù)據(jù)庫內(nèi)部因素
-
軟件環(huán)境
這4個的順序可以有所調(diào)整或者交換，但是對于系統(tǒng)的性能優(yōu)化一定要從全局出發(fā)。切勿一來就深入到某一個SQL語句的優(yōu)化，因為可能你花費大量的時間把一個SQL從20s 優(yōu)化到1s，但是整個系統(tǒng)的卡慢仍然存在。
***才是：
-
業(yè)務(wù)模型及架構(gòu)
-
代碼設(shè)計
實戰(zhàn)案例
不廢話了，開整開整，直接上干貨。
時間：2018年1月某天
事件：某醫(yī)院客戶 下午4點 突然出現(xiàn)大面積的卡慢。整個系統(tǒng)出現(xiàn)嚴重問題，信息中心電話打爆，醫(yī)院工程師手足無措。
萬幸的是我們給數(shù)據(jù)庫裝了‘攝像頭’，下面就從監(jiān)控錄像來看看發(fā)送了什么。然后加以解決。
硬件能力
CPU
在問題發(fā)生時間段內(nèi)CPU使用率在20%以下，正常。
Memory
從下面的圖像顯示，內(nèi)存使用正常。
頁生命周期
可用內(nèi)存
IO
IO隊列平均值很低，15.48 左右有個瞬時的高點，可留意這段時間有沒有批量的寫入。
總的來看，硬件資源是足夠的。
系統(tǒng)規(guī)模
問題發(fā)生時，每秒的批請求數(shù)并不是一個上升趨勢，反而有所下降。這是因為系統(tǒng)的擁堵，等待 ，影響了系統(tǒng)的吞吐量。
數(shù)據(jù)庫內(nèi)部因素
等待
慢語句
從會話和慢語句的趨勢圖可以看到，問題發(fā)生的時間和客戶描述完全吻合，我們可以斷定本身事故的確是慢在數(shù)據(jù)庫。
什么導(dǎo)致的慢
檢查者個時間段運行中的語句，可以發(fā)現(xiàn)下午15.58左右，數(shù)據(jù)庫中開始出現(xiàn)越來越多的CMEMTHREAD等待。
一直到1900頁16.08分的時候，出現(xiàn)了***達100個并發(fā)同時出現(xiàn)CMEMTHREAD等待。
什么是CMEMTHREAD等待
微軟官方的描述：在任務(wù)正在等待線程安全的內(nèi)存對象時發(fā)生。 當多個任務(wù)嘗試從同一個內(nèi)存對象分配內(nèi)存導(dǎo)致爭用時，等待時間可能會增加。
這個描述很晦澀，感覺還是完全不知道等待類型是怎么回事，應(yīng)該怎么處理這類問題。
實際上，從官方描述來看是內(nèi)存爭用的問題，但是實際上這個問題的關(guān)鍵在于多個任務(wù)的爭用，實際上是并發(fā)的執(zhí)行的問題。
場景
-
出現(xiàn)在數(shù)據(jù)庫編譯或重編譯時，將即席執(zhí)行計劃ad hoc plans 插入到計劃緩存中的時候
-
NUMA架構(gòu)下，內(nèi)存對象是按照節(jié)點來分區(qū)的
內(nèi)存對象有三種類型的（Global，Per Numa Node，Per CPU）。 SQL Server將允許對內(nèi)存對象進行分段，以便只有同一節(jié)點或CPU上的線程具有相同的底層CMemObj，從而減少來自其他節(jié)點或cpu的線程交互，從而提高性能和可伸縮性。減少內(nèi)存的并發(fā)爭用。
- SELECT
- type, pages_in_bytes,
- CASE
- WHEN (0x20 = creation_options & 0x20) THEN 'Global PMO. Cannot be partitioned by CPU/NUMA Node. TF 8048 not applicable.'
- WHEN (0x40 = creation_options & 0x40) THEN 'Partitioned by CPU.TF 8048 not applicable.'
- WHEN (0x80 = creation_options & 0x80) THEN 'Partitioned by Node. Use TF 8048 to further partition by CPU'
- ELSE 'UNKNOWN'
- END
- from sys.dm_os_memory_objects
- order by pages_in_bytes desc
如果你發(fā)現(xiàn)，Partitioned by Node 的內(nèi)存開銷是排在前面的，可以使用TRACE FLAG 8048來減少CMEMTHREAD等待。
從圖中可以看到，客戶的 Partitioned by Node 是比較靠后的，排在14位。
3. 補丁
這類場景是最常見的。如果在系統(tǒng)中發(fā)現(xiàn)出現(xiàn)大量的CMEMTHREAD等待，優(yōu)先考慮數(shù)據(jù)庫是不是已經(jīng)安裝***的補丁。
2008 r2: FIX: SQL Server 2008 R2 performs poorly when most threads wait for the CMEMTHREAD wait type if the threads use table variables or temp tables to load or update rowsets
2012 ,2014 當您執(zhí)行許多特殊查詢在 SQL Server 2012年或 SQL Server 2014 CMEMTHREAD 等待。
軟硬件環(huán)境
目前數(shù)據(jù)庫的版本是 11.0.5556.0 而前面提到的補丁，安裝后的版本是：11.0.5623.0
代碼設(shè)計
是什么語句產(chǎn)生了等待。
都是類似下面的語句，***時，并發(fā)超過100。
SELECT
* INTO #Tmp from TB where 1=2
特點如下：
1.語句簡單 開銷都小于5不會產(chǎn)生并行。
2.都采用了select into #temptable的形式。
就像上面分析的一樣，CMEMTHREAD等待是一個并發(fā)問題，而不是一個內(nèi)存問題。在其他方案行不通的時候，我們可以通過調(diào)整此類語句的寫法，減少CMEMTHREAD等待.
業(yè)務(wù)模型及架構(gòu)
目前系統(tǒng)是單機運行的狀態(tài)，這其實是很少見的。存在少量OLAP 和OLTP業(yè)務(wù)混合的情況。后續(xù)我們會給客戶規(guī)劃 讀寫分離 或者負載均衡的解決方案。
解決方案
安裝***的補丁
至少需要安裝前面發(fā)的解決等待問題的FIX。建議是直接安裝到目前為止***的2012 SP4補丁。
修改參數(shù)
optimize for ad hoc workloads 從0修改為1 。針對將即席執(zhí)行計劃ad hoc plans 插入到計劃緩存中的時候場景，減少ad hoc 查詢占用的內(nèi)存。
增加TEMPDB數(shù)據(jù)文件的個數(shù)
select * into #temptable 會產(chǎn)生大量的閂鎖爭用，防止在CMEMTHREAD 等待消除后，出現(xiàn)大量的pagelatch 閂鎖爭用。我經(jīng)歷過很多案例，解決了前面的一個擁堵之后，后面有產(chǎn)生了新的等待，導(dǎo)致性能更差了。請記住，優(yōu)化是一個長期的，循序漸進的過程。
遷移TEMPDB數(shù)據(jù)文件的位置
目前部分tempdb文件放在S，一般分放在D盤。建議都遷移到S盤(存儲上面)，增加tempdb的響應(yīng)速度。如果可能的話，使用SSD來***化tempdb的性能，將會是不錯的選擇。
優(yōu)化程序的代碼
修改代碼通常都是放在***面的，因為要牽涉的情況比較多。前面的手段80%的情況下，都可以解決問題。剩下的20%，我們需要，檢查程序中的邏輯，看看這些的語句都是什么業(yè)務(wù)產(chǎn)生的。什么條件會觸發(fā)這類業(yè)務(wù).對應(yīng)下面類似的語句都使用存儲過程，或者參數(shù)化后的方式，減少編譯和重編譯的次數(shù)。另外此類語句都會并發(fā)創(chuàng)建臨時表，可能通過調(diào)整tempdb的設(shè)置，加快此類語句的執(zhí)行速度，減少同一時間此類語句的并發(fā)數(shù)量。
優(yōu)化效果
經(jīng)過前面的幾個優(yōu)化手段，第二天開始，沒有再出現(xiàn)過一次CMEMTHREAD的等待。
等待
慢語句
總結(jié)
通過這篇文件你應(yīng)該已經(jīng)完全學會了數(shù)據(jù)庫性能調(diào)優(yōu)的思想。他告訴了我們出現(xiàn)問題時，怎么動手一步一步的排查問題，就像剝洋蔥一樣一層一層的剝開。
參考
微軟官方博客對這類等待的原理和如何調(diào)試：How It Works: CMemThread and Debugging Them
SQL Server 2016 對這里問題進行了進一步的優(yōu)化，詳細參考：SQL 2016 – It Just Runs Faster: Dynamic Memory Object (CMemThread) Partitioning
