Part 1
— 前言 —
壓力測試過程中，因為資源使用瓶頸等問題引發(fā)的最直接的性能問題是業(yè)務(wù)交易響應(yīng)時間偏大，TPS逐漸降低等。而問題定位分析通常情況下，最優(yōu)先排查的是監(jiān)控服務(wù)器資源利用率，例如先用TOP 或者nmon等查看CPU、內(nèi)存使用情況，然后在排查IO問題，例如網(wǎng)絡(luò)IO、磁盤IO的問題。 如果是磁盤IO問題，一般問題是SQL語法問題、MYSQL參數(shù)配置問題、服務(wù)器自身硬件瓶頸導(dǎo)致IOPS吞吐率問題。
今天主要是講解MYSQL 參數(shù)配置不合理導(dǎo)致在高并發(fā)下磁盤IO問題。
Part 2
— 三種問題 —
1、 打開日志跟蹤引起的磁盤IO問題
例如：MySQL的日志包括錯誤日志(ErrorLog)，更新日志(UpdateLog)，二進制日志(Binlog)，查詢?nèi)罩?QueryLog)，慢查詢?nèi)罩?SlowQueryLog)等，正常情況下，在生產(chǎn)系統(tǒng)或者壓力測試環(huán)境中很少有系統(tǒng)會時時打開查詢?nèi)罩尽Ｒ驗椴樵內(nèi)罩敬蜷_之后會將MySQL中執(zhí)行的每一條Query都記錄到日志中，會該系統(tǒng)帶來比較大的IO負擔(dān)，而帶來的實際效益卻并不是非常大。
2、 SQL寫法問題引起磁盤IO高
例如：曾經(jīng)在做某一個項目時，在看到數(shù)據(jù)庫磁盤IO使用率偏高，前端查詢業(yè)務(wù)交易loadrunner顯示事物響應(yīng)時間偏長，通過監(jiān)控工具抓取對應(yīng)SQL，通過計劃分析，發(fā)現(xiàn)該SQL中使用distinct 又多表關(guān)聯(lián)且是大表、然后使用order by，最終顯示10筆數(shù)據(jù)，而在產(chǎn)生中間過程數(shù)據(jù)進行篩選時，使用的是臨時表，并把數(shù)據(jù)放入臨時表中，內(nèi)存剛好設(shè)置不大，于是放到磁盤中導(dǎo)致IO偏高。
備注：MySQL在執(zhí)行SQL查詢時可能會用到臨時表，臨時表存儲，MySQL會先創(chuàng)建內(nèi)存臨時表，但內(nèi)存臨時表超過配置指定的值后，MySQL會將內(nèi)存臨時表導(dǎo)出到磁盤臨時表。
3、 MYSQL參數(shù)配置問題
MYSQL默認配置性能低下，只能通過并發(fā)下嘗試調(diào)整參數(shù)配置來逐步優(yōu)化數(shù)據(jù)庫性能，2017年底根據(jù)公司要求配合幫助某一家銀行業(yè)務(wù)系統(tǒng)做性能測試，因為測試環(huán)境硬件資源有限，我跟公司申請了幾臺過時的筆記本，然后根據(jù)生產(chǎn)環(huán)境軟件版本等配置要求，進行模擬搭建性能測試環(huán)境，基礎(chǔ)軟件包含：MYSQL5.6、centos7.2、tomcat7、 JDK1.7、redis。使用的是聯(lián)想L421 筆記本當(dāng)MYSQL數(shù)據(jù)庫服務(wù)器、L440當(dāng)tomcat應(yīng)用服務(wù)器，壓力測試工具loadrunner、并發(fā)用戶100，壓力測試業(yè)務(wù)場景：用戶登錄退出、相關(guān)票據(jù)信息查詢、電子匯票交易流程等，在壓力測試過程中發(fā)現(xiàn)部分交易在50用戶并發(fā)時，數(shù)據(jù)庫磁盤I0使用率都偏高，特別是寫操作一直很高，例如測試登錄退出交易，經(jīng)監(jiān)控數(shù)據(jù)庫磁盤IO率一直偏高，下面我將以此為例作為講解。
Part 3
— 優(yōu)化前后 —
優(yōu)化前
壓力測試時，數(shù)據(jù)庫磁盤IO使用率大于75%，響應(yīng)時間1.6秒，通過NMON監(jiān)控到的數(shù)據(jù)庫資源使用情況，如下圖一與圖二：
圖一：
圖二：
優(yōu)化后
數(shù)據(jù)庫服務(wù)器資源使用率：
圖三：
圖四：
Part 4
— 優(yōu)化內(nèi)容 —
通過優(yōu)化innndb等影響IO、內(nèi)存的一些參數(shù)后，性能問題明顯解決，優(yōu)化參數(shù)內(nèi)容，例如：innodb_write_io_threads、innodb_read_io_threads、innodb_flush_log_at_trx_commi等InnoDB 引擎優(yōu)化IO 子系統(tǒng)參數(shù)配置若干。
