使用阿里雲RDS for SQL Server性能洞察優化資料庫負載-初識性能洞察

簡介

  資料庫性能調優通常需要較高資料庫水平,並伴隨較多的前期準備工作,比如收集各種性能基準線、不同種類的性能指標、慢SQL日誌等,這通常費時費力且效果一般,當面對多個資料庫時總體擁有成本會大幅增加。今天資料庫早已邁入雲時代,藉助阿里雲RDS for SQL Server Clouddba這一免費工具,可以快速準確地降低阿里雲RDS for SQL Server資料庫負載優化成本與操作人員技能水平要求,從而達到將更多精力用於實現業務本身的,而不是資料庫上實現細節。

  本篇文章主要分享阿里雲Clouddba 性能洞察的基本原理與使用方式,並利用該平台診斷優化常見的性能問題。

 

如何評估資料庫負載情況?

  當問到,如何評估資料庫負載時,不同角色可能想到不同的方法,例如以下幾種:

 

  • 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所示:

圖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所示:

圖2.SQL執行時每個CPU的調度狀態

 

  當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,該功能的入口如圖

圖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資料庫調優的抽象方法論,就解決了兩個問題「縮小範圍」和「定位瓶頸」兩個問題:

圖4.性能調優4個步驟

 

  通俗點說,也就是解決了下面兩個問題:

  • 哪些SQL在特定時間對實例的負載影響最大
  • 這些SQL為什麼慢

 

  而具體如何實施優化,以及如何驗證優化效果,會在後續文章中進行講述。

 

USE CASE1:快速優化整體負載情況

  80 20法則同樣適用於資料庫,80%的負載都是由20%的 SQL產生,也就是說只要優化這20%的SQL就已經完成了80%的優化工作,進一步想,如果20%中的20%,也就是4%,優化這部分豈不是就可以完成80%*80%=64%的工作。因此很多場景下,優化頭部的幾個SQL就能完成絕大多數優化工作。

圖5.CPU 100%問題定位

 

  圖4我們可以看到,示例CPU使用率一直100%,在發生阻塞時會瞬間跌到個位數。我們觀察一個小時的AAS數據,看到下面單個Select的SQL的平均AAS為78,遠遠超過實例8C的規格,因此只要優化這一個SQL,該實例的問題基本就能夠得到解決。

  通過圖4的SQL「分析」功能,我們能夠快速根據執行計劃發現常見SQL慢的原因,包括索引缺失、參數類型轉換、統計資訊不準確等問題。

 

USE CASE2:找到特定時間段內資料庫響應時間變慢的原因

  這類場景也是一個經典場景,資料庫整體可能較長時間處於健康水平,但在業務高峰或特定時間段,存在資料庫負載壓力較大,業務側SQL較慢的場景。通常情況下,大多數資料庫僅存在一些指標維度的監控,比如通用的CPU、網路、IO。或者引擎側的指標,通常通過這些指標我們能猜測出大概範圍,但難以定位到具體語句,通過AAS,我們可以通過查看特定時間段的高負載定位到導致特定時間資料庫問題的語句,如圖6所示:

圖6.特定時間負載高

 

通過圖6,我們可以看到再特定2分鐘內有性能突發的毛刺,我們通過滑鼠拖拽放大該時間範圍,得到如圖7所示結果

圖7.拖拽後明顯看到兩個導致高AAS的語句

 

  通過圖7,我們可以快速定位到兩個產生性能毛刺的語句,並且注意到等待類型分別為Lock與Tran Log IO,由此根據圖4的調優理論,我們可以初步判斷是大量的更新操作產生的日誌IO負載,並由於這些語句之間的鎖阻塞導致鎖等待。這可以極大的降低調優成本。

 

 

小結

  使用性能洞察,在雲上我們可以做到不用任何額外成本,快速查看整體負載,查看負載細節,以及定位不同負載對應的SQL,從而可以幫我我們在雲上快速解決資料庫性能問題、並定期調優整體負載。

  而且更重要的是,性能洞察是免費的!!!阿里雲RDS for SQL Server全系列可用:-)