溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要講解了“分析數據庫實例性能調優利器Performance Insights”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“分析數據庫實例性能調優利器Performance Insights”吧！
阿里云RDS Performance Insights是RDS CloudDBA產品一項專注于用戶數據庫實例性能調優、負載監控和關聯分析的利器，以簡單直觀的方式幫助用戶迅速評估數據庫負載，資源等待的源頭和對應SQL查詢語句，以此來指導用戶在何時、何處、采取何種行動進行數據性能優化。
Performance Insights：中文翻譯過來叫性能洞察。
Active Session （AS）：RDS數據庫系統中，活躍的會話數量。
Average Active Session （AAS）：一段時間內，RDS數據庫中平均活躍會話數量。
Max Vcores：RDS數據庫實例最大可以使用到的CPU Cores數量。
AAS和MaxVcores來量化系統瓶頸
在文章開始，我們希望能夠把一個非常重要的問題解釋清楚：為什么可以使用AAS （平均活躍會話數）與RDS數據庫實例MaxVcores量化對比來作為系統瓶頸的判斷依據？我們的理由是：
首先，RDS數據庫系統中，我們認為最為重要的資源是CPU資源，因為其他所有資源都需要CPU來調度。
其次，CPU的并發處理能力，與CPU Cores的數量相關。假設在相當小的一個時間切片上，CPU對活躍會話（AS）處理能力瓶頸就是CPU Cores數量。即：CPU最多同時能夠處理與Cores數量均等的活躍會話數。
因此，我們可以用RDS數據庫系統中，平均活躍會話（AAS）數與MaxVcores數的量化對比，做為判定系統是否存在瓶頸的重要依據。
阿里云RDS Performance Insights能夠幫助我們的用戶快速方便、直接了當的發現數據庫實例負載，以及導致性能問題的SQL語句。目前Performance Insights頁面以三個方面承載我們的產品思路：
關鍵性能指標趨勢圖：關鍵資源利用率變化趨勢圖。
實時AAS變化趨勢圖：數據庫實例中平均活躍會話（Average Active Sessions）實時變化趨勢。
多維負載信息：展示多維度實例負載信息。
關鍵資源利用率趨勢圖
阿里云RDS Performance Insights關鍵性能指標的趨勢圖，可以從宏觀的角度幫助客戶發現實例負載的來源，比如：到底是CPU資源吃緊，IOPS過高？還是網絡開銷過大，又或是活躍連接數打滿？
實時AAS變化趨勢圖
從關鍵資源利用率趨勢圖部分，我們已經大致清楚了實例負載的來源。接下來，帶著這個問題，我們去看看目前實例中活躍會話的資源等待情況。那么，此時我們可以來到頁面的第二個部分：實時AAS變化趨勢圖。
從Performance Insights中的實時AAS變化趨勢圖中，我們可以非常清晰的發現RDS實例中的資源等待情況。比如上圖，我們可以分析出以下重要信息：
時間10:25 - 10:57之間，平均活躍會話遠遠大于實例CPU Cores數量24（幾個點低于CPU Cores），說明數據庫已經面臨比較大的系統瓶頸。
從AAS變化趨勢圖來看，幾乎是在等待藍色標示的資源，即CPU資源。
由此可見，我們使用Performance Insights中的實時AAS變化趨勢圖，可以非常清晰簡單，直接了當的找到用戶RDS實例負載來源，資源等待于何時、何處，以及變化規律。
多維度負載詳情
通Performance Insights中的實時AAS變化趨勢圖，掌握了實例負載來源，資源等待及變化規律，接下來用戶理所應當最關心的一個問題便是：到底導致這些實例負載的具體查詢語句是什么？哪個用戶導致的？哪個連接主機客戶端？哪個應用數據庫？這一系列的問題我們可以使用多維負載信息部分來解答。
從以上截圖的下半部分，我們可以方便的找出與AAS變化趨勢關聯的負載對應的SQL查詢語句，以及每個語句對AAS的貢獻的對比情況。當然，您也可以根據自己的需要切換為Waits，Users，Hosts，Commands，Databases和Status，分別表示資源等待，用戶，客戶端主機，命令類型，數據庫，進程狀態等維度查看。
Performance Insights架構
了解阿里云RDS Performance Insights能夠做什么以后，讓我們來看Performance Insights的設計架構圖，簡要概括為五個字：四層兩鏈路。
四層架構
RDS Performance Insights四層架構從上往下，依次為：
應用層：前端用戶可見，承載著我們產品的思路和邏輯，是終端用戶可見的產品呈現。
服務層：各系統API協調工作，為應用層提供應用數據服務，我們產品主要的業務邏輯處理層。
數據層：數據實時處理平臺，統計匯總，數據扁平化，實時計算，最終持久化到元數據庫中，為服務層提供數據。
采集層：從RDS實例中，采集有價值的基礎數據，為數據層輸入數據。
兩條鏈路
從數據鏈路來看Performance Insights，有兩條鏈路：
訪問鏈路：數據至上而下請求訪問，至下而上的數據返回。
采集鏈路：數據從生產到消費，從統計匯總到最終落庫整個生命過程。
典型案例
以下兩個典型案例，來看看Performance Insights如何一目了然，一針見血的幫助我們診斷分析數據庫系統瓶頸，資源等待和SQL查詢語句。
為什么CPU 100%了
XXX時間點SQL查詢變慢了
為什么CPU 100%了？
在我們多年的專家服務過程中， 遇到最多的用戶問題便是“為什么我的CPU 100%了”，來看看Performance Insights是如何庖丁解牛這個問題。
Performance Insights截圖
以下是該RDS實例，Performance Insights頁面截圖。
分析
我們從Performance Insights頁面截圖分析出以下幾個問題：
從資源利用率中CPU使用率和活躍會話數量來看：大概在 09:59 - 10:05，均有大幅上升。CPU使用率達到了100%，活躍會話（Active Sessions）達到了400+；
AAS變化趨勢中發現，這段時間內，系統瓶頸主要集中在CPU和Lock兩資源的等待，總的Active Sessions數遠遠超過CPU Cores（實例的CPU Cores為16），存在嚴重的系統瓶頸。
SQL語句詳情部分：非常清晰的看到排在第一位的SQL查詢語句是等待CPU資源，達到了96個活躍會話；第二位是Lock資源等待，達到了79個會話，可以點擊SQL語句，查看詳情。
XXX時間點SQL查詢變慢了
另外，用戶經常遇到的一個問題是“為什么我的SQL查詢語句突然變慢了”？
Performance Insights截圖
某RDS實例用戶反饋在16:05左右，原本執行很快的Update語句，突然變得很慢，16:08左右恢復正常，以下是該RDS實例
從Performance Insights，我們可以分析出：
從AAS變化趨勢圖中，發現大約從16:05:50秒開始，系統出現了大量等待Lock資源的活躍會話（圖中橙色顏色區域），達到了33個，遠超CPU Cores數。
從截圖最下部分SQL查詢中，發現等待Lock資源的SQL語句（第一條，橙色標示），恰巧是用戶抱怨變慢的Update操作語句。于是我們可以很快斷定，這個Update變慢的原因是資源被鎖住，導致等待鎖資源釋放時間過長，拉長了執行時間，即Update語句變慢了。
從AAS變化趨勢圖中，發現大約在16:07:20左右，等待鎖資源的活躍進程消失了，Update語句性能恢復正常，說明鎖資源已經釋放。
以上，我們從兩個特定的用戶案例可以看到Performance Insights可以簡單直觀，輕松愉悅的幫助用戶診斷問題，關聯分析系統瓶頸，資源等待和SQL查詢，取得了非常好的效果。
伴隨阿里云RDS Performance Insights第一期發布，我們已經可以幫助用戶快速發現RDS實例性能問題，以及導致性能問題的具體SQL查詢。但是，這遠遠不夠，我們還需要更深入的幫助我們的客戶自動化、智能化解決問題。
當前，用戶通過阿里云RDS Performance Insights找到了導致性能問題的具體查詢SQL語句后，接下來很自然的一個問題是，為什么這個查詢語句會導致性能問題？是缺失必要的索引？統計信息數據傾斜？查詢數據類型轉換？Non-SARG查詢等等？接下來，我們需要深入探索為什么SQL會導致性能問題。
當用戶知道了SQL語句為什么有性能問題以后，接下來的問題便是：我該怎么做才能解決性能問題？我們需要明確告訴用戶怎么辦就能夠解決性能問題。
隨著用戶能夠解決SQL語句性能問題以后，用戶接下來最為迫切的需求便是：阿里云能否幫我們預先發現、智能化、自動化處理解決這些類似的問題？
感謝各位的閱讀，以上就是“分析數據庫實例性能調優利器Performance Insights”的內容了，經過本文的學習后，相信大家對分析數據庫實例性能調優利器Performance Insights這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
