MYSQL數(shù)據(jù)庫服務(wù)CPU高問題分析與優(yōu)化

MYSQL數(shù)據(jù)庫服務(wù)CPU高問題分析與優(yōu)化

   MySQL服務(wù)性能監(jiān)控分析與優(yōu)化是永恒的主題，做為性能測試人員有時也要站在DBA角度出發(fā)進(jìn)行適當(dāng)分析與優(yōu)化，這也是性能測試人員能長期生存發(fā)展之路。而資源的使用監(jiān)控分析才是性能故障分析的根本首要任務(wù)。在數(shù)據(jù)庫服務(wù)器內(nèi)部，如果執(zhí)行的操作會嚴(yán)重受到內(nèi)存、CPU或磁盤吞吐量中任何一個的影響，則可以將它視為瓶頸。

   因此理解服務(wù)器如何運(yùn)行，資源損耗在哪些方面對問題進(jìn)行故障診斷是非常有價值有意義的活動，具體案例如下。

這些監(jiān)控分析優(yōu)化方法等細(xì)節(jié)我們在品課學(xué)院性能實(shí)戰(zhàn)課堂中都會以實(shí)戰(zhàn)方式進(jìn)行實(shí)操性測試監(jiān)控分析實(shí)踐理解學(xué)習(xí)，特別是資源利用問題花費(fèi)在什么地方，課堂中都會操作項目案例模擬講解，來提高學(xué)員對性能監(jiān)控分析的認(rèn)知。

1、  識別瓶頸

在分析性能問題時，首先需要識別瓶頸，然后將該瓶頸解決。產(chǎn)生瓶頸的原因通常有兩類，一類是由于錯誤的配置，另一類是達(dá)到了軟件或硬件的性能或可伸縮性的限制，例如SQL語法問題。

2、  識別CPU瓶頸

前面章節(jié)我們有講到《MYSQL數(shù)據(jù)庫服務(wù)磁盤IO高問題分析與優(yōu)化》有提到IO 問題故障分析與解決方案，而本章主要是講解CPU 問題定位分析與解決方案。

CPU時間開銷是最昂貴、最寶貴的服務(wù)器資源，并且系統(tǒng)總體性能往往對CPU使用率非常敏感。例如，用戶經(jīng)?？梢圆煊X到高CPU使用率的狀況，就是響應(yīng)時間慢，超時現(xiàn)象等。

3、瓶頸根源分析

MYSQL自身經(jīng)常會導(dǎo)致高CPU使用率的情形，包括執(zhí)行差效率的查詢、哈希連接或多表合并連接、參數(shù)設(shè)置不合理等。

4、  案例說明如下

測試場景，在壓力測試某銀行系統(tǒng)登錄退出時，因用戶登錄需要查詢對應(yīng)的客戶相關(guān)交易信息等，而需要涉及SQL查詢，這時LR 并發(fā)100用戶時，響應(yīng)時間5秒多，人工登錄發(fā)現(xiàn)出現(xiàn)超時錯誤信息，這時通過top命令監(jiān)控到CPU使用率超過90%，如下圖：

 4.1 前端頁面響應(yīng)超時：

    4.2 數(shù)據(jù)庫服務(wù)器資源使用率

       4.3 LR響應(yīng)時間指標(biāo)分析

      4.4 MYSQL 語法分析

 在監(jiān)控過程中發(fā)現(xiàn)若干SQL語法都是走全表掃描方式，導(dǎo)致響應(yīng)時間和CPU使用率偏高，其中一個SQL如下

4.6、  優(yōu)化方法

這時對表的需要檢索字段建立索引后各項性能指標(biāo)如下圖

這時 同樣是100用戶并發(fā)，如下圖建立索引前后響應(yīng)時間走勢圖：

SQL 檢索數(shù)據(jù)路徑：

發(fā)現(xiàn)雖然建立索引，響應(yīng)時間降低到2秒以下，但是數(shù)據(jù)庫服務(wù)器cpu資源使用率仍然70%以上，偏高，這時發(fā)現(xiàn)緩存命中率不高，針對query_cache適當(dāng)調(diào)整大小后，mysql數(shù)據(jù)庫cpu使用率講到30%以下和響應(yīng)時間1秒以下，如下圖。

響應(yīng)時間指標(biāo)如下：