共計 2206 個字符，預(yù)計需要花費 6 分鐘才能閱讀完成。
自動寫代碼機(jī)器人，免費開通
這篇文章主要介紹 mysql 服務(wù)器的性能分析，文中介紹的非常詳細(xì)，具有一定的參考價值，感興趣的小伙伴們一定要看完！
3.3.3 使用性能剖析：有限 3.4 診斷簡歇性問題
如系統(tǒng)偶爾停頓、慢查詢、喚影問題，盡量不要使用試錯的方式解決問題：風(fēng)險大
3.4.1 單條查詢問題還是服務(wù)問題使用 SHOW GLOBAL STATUS
較高頻率：1s/ 次執(zhí)行該命令鋪獲數(shù)據(jù)，問題出現(xiàn)通過計數(shù)器的
使用 SHOW PROCESSLIST【參考】顯示哪些線程正在運行
使用查詢?nèi)罩?
開啟慢查詢，設(shè)置全局的 long_query_time=0, 確認(rèn) all 連接采用了新設(shè)置（可能需要重置 all 連接使生效）
注意吞吐量突然下降時間段的日志，查詢是在完成階段才寫入到慢查詢?nèi)罩镜?
好的工具事半功倍：tcpdump、pt-query-digest、Percona Server
理解發(fā)現(xiàn)的問題
可視化數(shù)據(jù)：gnuplot /R（繪圖工具）
gnuplot：
安裝 一些命令： 常用技巧 入門教程 2 Gnuplot 數(shù)據(jù)可視化
建議：先使用前兩種方法，開銷低且通簡單 shell 腳本或反復(fù)執(zhí)行的查詢交互式收集數(shù)據(jù)
3.4.2 鋪獲診斷數(shù)據(jù)
現(xiàn)間歇性問題，盡量多收集數(shù)據(jù)（不只是問題出現(xiàn)時的）
弄清楚：1、有區(qū)分 何時出現(xiàn)了問題 的方法：觸發(fā)器；2、收集診斷數(shù)據(jù)的工具
診斷觸發(fā)器
誤差：在沒有發(fā)生問題期間收集了很多診斷數(shù)據(jù)，浪費時間（這個和前的、仔細(xì)讀一下 不矛盾）
漏檢：在問題出現(xiàn)時沒有鋪獲到數(shù)據(jù)，錯失了機(jī)會，開始收集前確認(rèn)觸發(fā)器能夠真正地識別問題
好的觸發(fā)器：
找到些能和正常時的閾值進(jìn)行比較的指標(biāo)
選擇一個合適的閾值：足夠高（正常時不會觸發(fā)）、不能太高（問題發(fā)生時不錯過）
推薦工具 pt-stalk【參考】【2】觸發(fā)器，設(shè)定到某個條件記錄 配置需監(jiān)控的變量 閾值 檢查的頻率
收集什么樣的數(shù)據(jù)
執(zhí)行時間：工作的時間和等待的時間
在需要的時間段內(nèi)收集 all 能收集的數(shù)據(jù)
未知問題發(fā)生的原因：1、服務(wù)器需做大量工作、導(dǎo)致大量消耗 CPU；2、在等待資源釋放
不同的方法收集診斷數(shù)據(jù)，確認(rèn)原因：
1、剖析報告：確認(rèn)是否有太多工作，工具：tcpdump 監(jiān)聽 TCP 流量 模式開閉慢查詢?nèi)罩?
2、等待分析：確認(rèn)是否存在大量等待，GDB 堆棧跟蹤信息、show processlist ，show innodb status 觀察線程、事務(wù)狀態(tài)
解釋結(jié)果數(shù)據(jù)
目的：1、問題是否真的發(fā)生了；2、是否有明顯的跳躍性變化
工具：
oprofile 利用 cpu 硬件層面提供的性能計數(shù)器 (performance counter)，通過計數(shù)采樣，幫助我們從進(jìn)程、函數(shù)、代碼層面找出占用 cpu 的 罪魁禍?zhǔn)住嵗緟⒖肌?/p>
opreport 命令，分別從進(jìn)程和函數(shù)層面查看 cpu 使用情況的方法
samples | %|
-----------------------------------------------------
鏡像內(nèi)發(fā)生的采樣次數(shù) 采樣次數(shù)所占總采樣次數(shù)的百分比 鏡像名稱
opannotate 命令可顯示代碼層面占用 cpu 的統(tǒng)計信息
GDB:Linux 應(yīng)用程序開發(fā)中，最常用的調(diào)試器是 gdb(調(diào)試的對象是可執(zhí)行文件)，它可以在程序中設(shè)置斷點、查看變量值、一步一步跟蹤程序的執(zhí)行過程 (數(shù)據(jù)、源碼）、查看內(nèi)存、堆棧信息。利用調(diào)試器的這些功能可以方便地找出程序中存在的非語法錯誤。【參考】【參考】語法和實例
3.4.3 一個診斷案例
間歇性性能問題，具備 MySQL、innodb、GNU/Linux 相關(guān)知識
明確：1、問題是什么，清晰描述；2、為解決問題已做過什么操作？
開始：1、了解服務(wù)器的行為；2、梳理服務(wù)器的狀態(tài) 參數(shù)配置 軟硬件環(huán)境（pt-summary pt-mysql-summary）
不要被離題太多的各種情況分散了注意力，問題寫在紙條上，檢查一個劃掉一個
是原因還是結(jié)果？？？
資源變得效率低下可能的原因：
1、資源過度使用，余額不足；2、資源未被正確匹配；3、資源損壞或失靈
3.5 其他剖析工具
USER_STATISTICS: 一些表對數(shù)據(jù)庫活動進(jìn)行測量、審計
strace：調(diào)查系統(tǒng)調(diào)用情況，使用實際時間、不可預(yù)期性、開銷的，oprofile 使用花費 CPU 周期
小結(jié)：
定義性能最有效的方法是響應(yīng)時間
無法測量便無法有效優(yōu)化，性能優(yōu)化工作需要基于高質(zhì)量、全方位及完整的響應(yīng)時間測量
測量的最佳開始點是應(yīng)用程序，即使問題出在底層的數(shù)據(jù)庫，借助良好的測量較容易發(fā)現(xiàn)問題
大多數(shù)系統(tǒng)無法完整地測量，測量有時候也會有錯誤的結(jié)果，想辦法繞過些限制，要能意識到方法的缺陷和不確定性在哪
完整的測量會產(chǎn)生大量需要分析的數(shù)據(jù)，so 需要用到剖析器（最佳工具）
剖析報告：匯總信息，掩蓋和丟棄了很多細(xì)節(jié)，不會告訴你缺了什么，不能完全依賴
兩種消耗時間的操作：工作或等待，almost 剖析器只能測量因工作而消耗的時間，so 等待分享有時候是很有用的補(bǔ)充，特別是 cpu 利用率低但工作一直無法完成的情況
優(yōu)化和提升兩回事，當(dāng)繼續(xù)提升的成本超過收益時，應(yīng)停止優(yōu)化
注意你的直接，思路，決策盡量基于數(shù)據(jù)
in a words: 首先澄清問題、選擇合適技術(shù)、善用工具、足夠細(xì)心、邏輯清晰且堅持下去，不要把原因和結(jié)果搞混，在確定問題前不要隨便針對系統(tǒng)做變動
以上是“mysql 服務(wù)器的性能分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關(guān)知識，歡迎關(guān)注丸趣 TV 行業(yè)資訊頻道！
向 AI 問一下細(xì)節(jié)
