【MySQL資料庫】第三章解讀：伺服器效能剖析 （下）

容我感慨一下：DBA真的不是蓋的

3.3.3使用效能剖析：有限

3.4診斷簡歇性問題

如系統偶爾停頓、慢查詢、喚影問題，盡量不要使用試錯的方式解決問題：風險大

3.4.1單條查詢問題還是服務問題

使用SHOW GLOBAL STATUS

較高頻率：1s/次執行該命令鋪獲資料，問題出現通過計數器的

使用SHOW PROCESSLIST 【參考】顯示哪些線程正在運行

使用查詢日誌

開啟慢查詢，設定全域的long_query_time=0,確認all串連採用了新設定（可能需要重設all串連使生效）

注意輸送量突然下降時間段的日誌，查詢是在完成階段才寫入到慢查詢日誌的

好的工具事半功倍：tcpdump、pt-query-digest、Percona Server

理解發現的問題

可視化資料：gnuplot /R（繪圖工具）

gnuplot：

安裝 一些命令： 常用技巧 入門教程 2 Gnuplot 資料視覺效果

建議：先使用前兩種方法，開銷低且通簡單shell指令碼或反覆執行的查詢互動式收集資料

3.4.2鋪獲診斷資料

現間歇性問題，盡量多收集資料（不只是問題出現時的）

弄清楚：1、有區分 何時出現了問題 的方法：觸發器；2、收集診斷資料的工具

診斷觸發器

誤差：在沒有發生問題期間收集了很多診斷資料，浪費時間（這個和前的、仔細讀一下 不矛盾）

漏檢：在問題出現時沒有鋪獲到資料，錯失了機會，開始收集前確認觸發器能夠真正地識別問題

好的觸發器：

找到些能和正常時的閾值進行比較的指標

選擇一個合適的閾值：足夠高（正常時不會觸發）、不能太高（問題發生時不錯過）

推薦工具pt-stalk【參考】【2】觸發器，設定到某個條件記錄 配置需監控的變數 閾值 檢查的頻率

收集什麼樣的資料

執行時間：工作的時間和等待的時間

在需要的時間段內收集all能收集的資料

未知問題發生的原因：1、伺服器需做大量工作、導致大量消耗CPU；2、在等待資源釋放

不同的方法收集診斷資料，確認原因：

1、剖析報告：確認是否有太多工作，工具：tcpdump 監聽TCP流量 模式開閉慢查詢日誌

2、等待分析：確認是否存在大量等待，GDB堆疊追蹤資訊、show processlist ，show innodb status觀察線程、事務狀態

解釋結果資料

目的：1、問題是否真的發生了；2、是否有明顯的跳躍性變化

工具：

oprofile利用cpu硬體層面提供的效能計數器(performance counter)，通過計數採樣，協助我們從進程、函數、代碼層面找出佔用cpu的"罪魁禍首"。執行個體【參考】

opreport命令，分別從進程和函數層面查看cpu使用方式的方法

 samples |                            %|-----------------------------------------------------     鏡像內發生的採樣次數     採樣次數所佔總採樣次數的百分比      鏡像名稱

opannotate命令可顯示代碼層面佔用cpu的統計資訊

GDB:Linux應用程式開發中，最常用的調試器是gdb(調試的對象是可執行檔)，它可以在程式中設定斷點、查看變數值、一步一步跟蹤程式的執行過程(資料、源碼）、查看記憶體、堆棧資訊。利用調試器的這些功能可以方便地找出程式中存在的非語法錯誤。【參考】【參考】 文法和執行個體

3.4.3一個診斷案例

間歇性效能問題，具備MySQL、innodb、GNU/Linux相關知識

明確：1、問題是什麼，清晰描述；2、為解決問題已做過什麼操作？

開始：1、瞭解伺服器的行為；2、梳理伺服器的狀態 參數配置 軟硬體環境（pt-summary pt-mysql-summary）

不要被離題太多的各種情況分散了注意力，問題寫在紙條上，檢查一個劃掉一個

是原因還是結果？？？

資源變得效率低下可能的原因：

1、資源過度使用，餘額不足；2、資源未被正確匹配；3、資源損壞或失靈

3.5其他剖析工具

USER_STATISTICS:一些表對資料庫活動進行測量、審計

strace：調查系統調用情況，使用實際時間、不可預期性、開銷的，oprofile使用花費CPU周期

小結：

• 定義效能最有效方法是回應時間

• 無法測量便無法有效最佳化，效能最佳化工作需要基於高品質、全方位及完整的回應時間測量

• 測量的最佳開始點是應用程式，即使問題出在底層的資料庫，藉助良好的測量較容易發現問題

• 大多數系統無法完整地測量，測量有時候也會有錯誤的結果，想辦法繞過些限制，要能意識到方法的缺陷和不確定性在哪

• 完整的測量會產生大量需要分析的資料，so需要用到剖析器（最佳工具）

• 剖析報告：匯總資訊，掩蓋和丟棄了很多細節，不會告訴你缺了什麼，不能完全依賴

• 兩種消耗時間的操作：工作或等待，almost剖析器只能測量因工作而消耗的時間，so等待分享有時候是很有用的補充，特別是cpu利用率低但工作一直無法完成的情況

• 最佳化和提升兩回事，當繼續提升的成本超過收益時，應停止最佳化

• 注意你的直接，思路，決策盡量基於資料

in a words:首先澄清問題、選擇合適技術、善用工具、足夠細心、邏輯清晰且堅持下去，不要把原因和結果搞混，在確定問題前不要隨便針對系統做變動

相關文章：

【MySQL資料庫】第二章解讀：MySQL基準測試

【MySQL資料庫】第三章解讀：伺服器效能剖析（上）