mysql的瓶颈_MySQL瓶颈分析与优化
作者：蔣樂(lè)興
簡(jiǎn)介
通過(guò)sysbench的oltp_read_write測(cè)試來(lái)模擬業(yè)務(wù)壓力、以此來(lái)給指定的硬件環(huán)境配置一份比較合理的MySQL配置文件。
環(huán)境介紹
硬件配置
軟件環(huán)境
優(yōu)化層級(jí)與指導(dǎo)思想
優(yōu)化層級(jí)
MySQL數(shù)據(jù)庫(kù)優(yōu)化可以在多個(gè)不同的層級(jí)進(jìn)行，常見(jiàn)的有：
SQL優(yōu)化
參數(shù)優(yōu)化
架構(gòu)優(yōu)化
本文重點(diǎn)關(guān)注：參數(shù)優(yōu)化
指導(dǎo)思想
日志先行 -- 一個(gè)事務(wù)能否成功提交的關(guān)鍵是日志是否成功落盤(pán)，與數(shù)據(jù)沒(méi)有太大的關(guān)系；也就是說(shuō)對(duì)寫(xiě)的優(yōu)化可以表述為各方面的資源向?qū)懖僮鲀A斜。
瓶頸分析 -- 通過(guò)show global status 的各個(gè)計(jì)數(shù)器的值基本上就能分析出當(dāng)前瓶頸所在，再結(jié)合一些簡(jiǎn)單的系統(tǒng)層面的監(jiān)控工具如top iostat 就能明確瓶頸。
整體性能是“讀”&“寫(xiě)”之間的再平衡。
優(yōu)化過(guò)程
優(yōu)化前
my.cnf中的內(nèi)容(關(guān)鍵部分)
圖像地址：
http://www.sqlpy.com/mysqlz/tuninglog/result/cm16c256g4096ssd/0/
監(jiān)控?cái)?shù)據(jù)
show global status 中Innodb_data_pending_fsyncs 這個(gè)status比較高；
iostat的util項(xiàng)有比較明顯的波峰，峰值使用率高達(dá)85%；
監(jiān)控?cái)?shù)據(jù)分析與優(yōu)化思路
對(duì)監(jiān)控?cái)?shù)據(jù)有兩種可能的解釋：
由于最小化的安裝的buffer_pool_size比較小，所以會(huì)頻繁的觸發(fā)innodb_buffer_pool的最大臟頁(yè)的限制，使得innodb進(jìn)入暴力刷盤(pán)的模式，這種情況下io使用率會(huì)明顯上升。
redo日志重用。 最終的影響可能是兩者的疊加，這里先從buffer_pool開(kāi)始優(yōu)化。
優(yōu)化緩沖池
my.cnf中的內(nèi)容(關(guān)鍵部分)
圖像地址：
http://www.sqlpy.com/mysqlz/tuninglog/result/cm16c256g4096ssd/1/
監(jiān)控?cái)?shù)據(jù)
show global status 中Innodb_data_pending_fsyncs 這個(gè)status減小到了 1；
iostat的util項(xiàng)峰值有所下降；
從性能圖像可以看出增大innodb_buffer_pool_size的值后、性能的峰值所對(duì)應(yīng)的并發(fā)更高了(當(dāng)innodb_buffer_pool_size默認(rèn)的128M調(diào)整到200G時(shí)innodb_buffer_pool_instances自動(dòng)增大到了8)
調(diào)整innodb_buffer_pool_size前后的性能對(duì)比
性能大概提高3倍
圖像地址：
http://www.sqlpy.com/mysqlz/tuninglog/compare/cm16c256g4096ssd/0/1/
監(jiān)控?cái)?shù)據(jù)分析與優(yōu)化思路
針對(duì)innob_buffer_pool_size的調(diào)整取得了一定的收獲，下面將要調(diào)整的就是針對(duì)redo重用的情況了，也就是說(shuō)我們要增大innodb_log_files_in_group和innodb_log_file_size到一個(gè)合適的值。
innob_buffer_pool_size取得的收獲還可以進(jìn)一步擴(kuò)大，那就是增大innodb_buffer_pool_instances的值。
優(yōu)化日志文件
根據(jù)對(duì)之前測(cè)試的記錄每完成一組測(cè)試LSN增大4.5G、測(cè)試持續(xù)時(shí)間大概是5分鐘；理論上把redo文件增大到5G可以做到整個(gè)測(cè)試的過(guò)程中不發(fā)生日志重用、這樣的話測(cè)試的跑分會(huì)更高、曲也線更平滑，不過(guò)這個(gè)會(huì)影響數(shù)據(jù)庫(kù)宕機(jī)恢復(fù)的時(shí)間。MySQL在默認(rèn)配置下innodb_log_files_in_group=2，innodb_log_file_size=48M也就是說(shuō)跑完一組測(cè)試redo日志要刷新48輪(1024*4.5/96 ==48)?先看一下把日志刷新減少到9輪的情況。
my.cnf中的內(nèi)容(關(guān)鍵部分)
圖像地址：
http://www.sqlpy.com/mysqlz/tuninglog/result/cm16c256g4096ssd/2/
調(diào)整innodb_log_files_in_group&innodb_log_file_size前后的性能對(duì)比
性能大概提高2倍
圖像地址：
http://www.sqlpy.com/mysqlz/tuninglog/compare/cm16c256g4096ssd/1/2/
現(xiàn)在看一下日志重用控制在一輪(5G)之內(nèi)的性能表現(xiàn)
my.cnf中的內(nèi)容(關(guān)鍵部分)
圖像地址：
http://www.sqlpy.com/mysqlz/tuninglog/result/cm16c256g4096ssd/3/
調(diào)整innodb_log_files_in_group&innodb_log_file_size前后的性能對(duì)比
性能大概提高2倍
圖像地址：
http://www.sqlpy.com/mysqlz/tuninglog/compare/cm16c256g4096ssd/2/3/
監(jiān)控?cái)?shù)據(jù)分析與優(yōu)化思路
增大redo到5G的情況下由于整個(gè)測(cè)試過(guò)程中幾乎沒(méi)有日志文件重用的問(wèn)題，這樣也就規(guī)避由些引發(fā)的大量數(shù)據(jù)刷盤(pán)行為，所以性能曲線也就更平滑了。
通過(guò)show global status 發(fā)現(xiàn)Table_open_cache_overflows=200W+、Thread_created=2k+
%Cpus : 80.5 us, 13.8 sy, 0.0 ni, 5.4 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st?95%的使用率cpu資源成了大問(wèn)題，這個(gè)使用率下能調(diào)整的參數(shù)不多了
對(duì)磁盤(pán)的監(jiān)控?cái)?shù)據(jù)表明util的峰值已經(jīng)下降到14%、磁盤(pán)已經(jīng)不在是問(wèn)題；所以針對(duì)innodb_buffer_pool_size、innodb_log_files_in_group&innodb_log_file_size 這兩次優(yōu)化的進(jìn)入一步優(yōu)化innodb_buffer_pool_instances、innodb_log_buffer_size 先不進(jìn)行；在些采用“抓大放小”的方式先調(diào)整表緩存與線程緩存。
優(yōu)化其它已知項(xiàng)
cpu使用率達(dá)到了95%，看到這個(gè)數(shù)值有一種發(fā)自?xún)?nèi)心的無(wú)力感，所以打算所目前status中能明確的一些問(wèn)題直接一起調(diào)整了；增大table_open_cache&table_open_cache_instances用于優(yōu)化表緩存、增大thread_cache_size使cpu不用頻繁的創(chuàng)建銷(xiāo)毀線程。
my.cnf中的內(nèi)容(關(guān)鍵部分)
圖像地址：
http://www.sqlpy.com/mysqlz/tuninglog/result/cm16c256g4096ssd/4
調(diào)整前后的比較
圖像地址：
http://www.sqlpy.com/mysqlz/tuninglog/compare/cm16c256g4096ssd/3/4/
總結(jié)
一、考慮到cpu使用率已經(jīng)達(dá)到95%且增加物理cpu不現(xiàn)實(shí)的情況下，決定MySQL參數(shù)優(yōu)化到此為止；最后來(lái)看一眼這次優(yōu)化成果。
圖像地址：
http://www.sqlpy.com/mysqlz/tuninglog/compare/cm16c256g4096ssd/0/4/
二、前面由于篇幅只給出配置文件的一部分、現(xiàn)在我們來(lái)看一下完整的配置文件。
說(shuō)明
之所以max_prepared_stmt_count要調(diào)整到這么是因?yàn)閟ysbench的oltp_read_write這個(gè)測(cè)試會(huì)用于prepare語(yǔ)句、如果這個(gè)值不夠大的話我們測(cè)試不了800+并發(fā)，你測(cè)試sysbench其它oltp用例可能不用這么做，同理max_connections的配置也是如此(不過(guò)它確實(shí)設(shè)置的大了點(diǎn))
有些參數(shù)在優(yōu)化過(guò)程中我并沒(méi)有調(diào)整主要原因有兩個(gè)：
①.這是有方法論指導(dǎo)的優(yōu)化、它更像定向爆破，所以沒(méi)用的我不去動(dòng)、在關(guān)鍵參數(shù)上調(diào)整后已經(jīng)解決問(wèn)題的情況下，其它相關(guān)的參數(shù)我更加傾向不動(dòng)。
②.對(duì)于從show global status 中能看出非常明確指向的我也會(huì)采取多個(gè)參數(shù)一起調(diào)整的策略。
總結(jié)
以上是生活随笔為你收集整理的mysql的瓶颈_MySQL瓶颈分析与优化的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： mysql数据库与oracle_orac
- 下一篇： flowable支持的mysql版本_F