客戶的困擾
前幾天某程式設計師小王向阿里雲諮詢他的SQL Server資料庫整體負載較高，是否有優化的方法？前幾天另外一個工單則是需要阿里雲工程師幫忙定位某一個時刻的資料庫性能尖刺的問題。
這些都是常見的性能診斷工單，其實資料庫性能診斷不僅對其資料庫技能要求較高，而且需要大量的前期準備工作，如收集各種性能基線、性能指標和慢SQL日誌等，尤其是面對多資料庫性能調優時，往往事倍功半。
如何評估資料庫負載情況？如何評估資料庫
當問到，如何評估資料庫負載時，不同角色可能想到不同的方法，例如以下幾種：
- QPS/TPS
- 資源使用: IOPS CPU 內存
- SQL執行時間
- 並發量
- ApplicatIOn業務反饋
上述每一種評價方法都較為片面且作為對實際調優的參考也較為困難。
通常情況下，我們評價資料庫資源負載是一個較為複雜的事情，需要我們對關係資料庫有一個較為全面的理解才行，但作為資料庫的使用者，大多數人不需要對資料庫進行深入學習，因此，我們傾向於簡化指標。
比如說，我們會只看CPU、IO、內存等指標看資料庫是否存在問題，這些指標適用於監控大多數應用，但對於資料庫來說可能並不能夠較為正確的反映資料庫內發生了什麼，以及我們該如何處理。我們還要結合很多資料庫特有的指標綜合判斷，比如各種SQL Server專用的性能計數器、DMV、等待類型、長事務、網絡、活動連接等等。但這些信息需要我們對資料庫自身有一個高級的了解，這使得評估資料庫的負載成為一個較高門檻的工作。
下面我們不妨換一個思路，關係資料庫本身是一個同步調用的過程，也就是說，從應用程式發起SQL，到資料庫返回結果，是同步的，資料庫不完成該請求，那麼應用程式無法收到結果，在此期間應用程式與資料庫之間的Session就是所謂的「Active」狀態，因此我們可以嘗試不再從資源使用的角度出發評估資料庫負載，而簡化為一個簡單的指標-AAS（Average Active Session），也就是活躍會話數量。
什麼是AAS概念？
設想一下，當你開車去一個目的地時，你更關注的是什麼？目的地的距離？路上是否堵車？到目的地是否有停車位置？等等
你會關心汽車狀態嗎？或許會，但你需要了解發動機原理、汽車的相關原理才能正確判斷車的狀態是否正常嗎？我們只需通過儀錶盤幾個簡單的指標和報警燈做一個簡單的判斷即可。
資料庫也是一樣，絕大多數用戶的場景並不需要理解資料庫引擎底層原理，而是更多關注如何使用資料庫，當然發燒友另說。
我們通過使用AAS的概念，提供了一種簡單、抽象的評估方法，也就是資料庫的活動連接數來衡量資料庫的總體負載，以及每種SQL對負載的貢獻，把資料庫各種metric匯總為一個簡單的指標----AAS。
從而使得用戶使用該抽象的概念評估資料庫負載，用戶僅需要對比AAS與CPU核數來評估當前負載是否超出當前實例的能力，這極大的降低了用戶需要對資料庫技能的要求，用戶可以花更多精力在業務邏輯而不是資料庫技術細節上。優化器、執行計劃、執行引擎，Buffer Pool，這些資料庫的技術細節我們都可以減少了解。
一個AAS概念簡單的圖形示例如圖1所示：
橫軸Time為時間，假設有3個長連接（也就是上圖中的User），每個連接根據應用負載向資料庫發送SQL請求，當時間為1時，User1連接正在執行SQL，並使用CPU資源，User2正在等待鎖資源，User3沒有負載，因此時間1的AAS值為2，時間2的AAS值為3，以此類推。
那麼AAS的值是2還是3究竟是高還是低？這取決於當前資料庫所擁有的CPU Core數量，每一個Core維護一個完整的SQL執行周期，如圖2所示：
當AAS值<=CPU核數時，通常來講資料庫的負載沒有額外等待，當前負載不需要額外等待其他CPU的調度，是AAS比較理想的狀態。
設想一個場景，你作為資料庫的運維人員，開發或業務方找到你說，嗨，資料庫出問題了。通過AAS，你可以簡單的根據AAS一個指標，初步縮小排查範圍，確定問題是否真正的出在資料庫。
一個簡單的AAS與實例核數的對比關係如下：
- AAS ≈0 資料庫無明顯負載，異常在應用側
- AAS < 1 資料庫無阻塞
- AAS< Max CPUs 有空餘CPU核，但可能存在單個Session打滿或資源（OLAP）
- AAS> Max CPUs 可能存在性能問題，但存在特殊情況
- AAS>> Max CPUs 存在嚴重性能問題，但存在特殊情況
案例解決
通過圖3我們可以看到性能洞察功能的UI，該功能的入口如圖
上下兩部分，上部分是按時間序列展示每個時間段的AAS負載情況，下部分是按照不同維度由高到底展示不同維度資源所占的負載，默認以SQL維度為主。
上部分可以看到各時間段負載，每種資源所占比例，比如圖中藍色展示的是CPU，其中重要的是當前實例規格的核數（max Vcores: 32），如果AAS值超過實例所擁有的CPU核數，我們就知道當前實例負載處於超標狀態，圖3所示負載一直處於10左右，低於Max Vcores 32，可以知道資料庫整體負載處於健康水位。
那從哪知道這些負載的來源？可以通過圖3下面的部分看到對應的SQL，以及每個SQL所貢獻的AAS比例，例如圖中可以看到第一條SQL全部為橙色，值為1.7056，該值說明在給定時間段內，該語句存在的平均會話是1.7次。而主要是等待Lock資源，這說明該語句的瓶頸在於鎖。
因此我們注意到第一個語句AAS貢獻最高，且等待瓶頸在於鎖，根據圖4資料庫調優的抽象方法論，就解決了兩個問題「縮小範圍」和「定位瓶頸」兩個問題：
通俗點說，也就是解決了下面兩個問題：
- 哪些SQL在特定時間對實例的負載影響最大
- 這些SQL為什麼慢
而具體如何實施優化，以及如何驗證優化效果，會在後續文章中進行講述。
USE CASE1：快速優化整體負載情況
80 20法則同樣適用於資料庫，80%的負載都是由20%的 SQL產生，也就是說只要優化這20%的SQL就已經完成了80%的優化工作，進一步想，如果20%中的20%，也就是4%，優化這部分豈不是就可以完成80%*80%=64%的工作。因此很多場景下，優化頭部的幾個SQL就能完成絕大多數優化工作。
圖4我們可以看到，示例CPU使用率一直100%，在發生阻塞時會瞬間跌到個位數。我們觀察一個小時的AAS數據，看到下面單個Select的SQL的平均AAS為78，遠遠超過實例8C的規格，因此只要優化這一個SQL，該實例的問題基本就能夠得到解決。
通過圖4的SQL「分析」功能，我們能夠快速根據執行計劃發現常見SQL慢的原因，包括索引缺失、參數類型轉換、統計信息不準確等問題。
USE CASE2：找到特定時間段內資料庫響應時間變慢的原因
這類場景也是一個經典場景，資料庫整體可能較長時間處於健康水平，但在業務高峰或特定時間段，存在資料庫負載壓力較大，業務側SQL較慢的場景。通常情況下，大多數資料庫僅存在一些指標維度的監控，比如通用的CPU、網絡、IO。或者引擎側的指標，通常通過這些指標我們能猜測出大概範圍，但難以定位到具體語句，通過AAS，我們可以通過查看特定時間段的高負載定位到導致特定時間資料庫問題的語句，如圖6所示：
通過圖6，我們可以看到在特定2分鐘內有性能突發的毛刺，我們通過滑鼠拖拽放大該時間範圍，得到如圖7所示結果
通過圖7，我們可以快速定位到兩個產生性能毛刺的語句，並且注意到等待類型分別為Lock與Tran Log IO，由此根據圖4的調優理論，我們可以初步判斷是大量的更新操作產生的日誌IO負載，並由於這些語句之間的鎖阻塞導致鎖等待。這可以極大的降低調優成本。
回顧
通過上面的案例分析，我們最終成功幫助客戶解決了問題。
今天資料庫早已邁入雲時代，藉助阿里雲RDS for SQL Server Clouddba這一免費工具，可以快速準確地降低阿里雲RDS for SQL Server資料庫負載優化成本與操作人員技能水平要求，從而達到將更多精力用於實現業務本身的，而不是資料庫上實現細節。使用性能洞察，在雲上我們可以做到不用任何額外成本，快速查看整體負載，查看負載細節，以及定位不同負載對應的SQL，從而可以幫我們在雲上快速解決資料庫性能問題、並定期調優整體負載。
作者信息
宋沄劍(沄跡) RDS產品部SQL Server產品線技術專家，負責SQL Server產品相關開發工作，善於分析各類疑難雜症。
原文連結：http://click.aliyun.com/m/1000351332/
本文為阿里雲原創內容，未經允許不得轉載。