目前在系統(tǒng)里面, 我們可以通過perf 或者 pt-pmp 匯總堆棧的方式來查看系統(tǒng)存在的熱點, 但是我們僅僅能夠知道哪些地方是熱點, 卻無法定量的說這個熱點到底有多熱, 這個熱點占整個訪問請求的百分比是多少? 是10%, 還是40%, 還是80%?

所以我們需要一個定量分析系統(tǒng)瓶頸的方法以便于我們進(jìn)行系統(tǒng)優(yōu)化.

本文通過Performance_schema 來進(jìn)行定量的分析系統(tǒng)性能瓶頸.

原理如下:

performance_schema.events_waits_summary_global_by_event_name 這里event_name 值得是具體的mutex/sx lock, 比如trx_sys->mutex, lock_sys->mutex 等等, 這個table 保存的是匯總信息.

具體performance_schema 信息在這里 https://dev.mysql.com/doc/mysql-perfschema-excerpt/8.0/en/performance-schema-wait-summary-tables.html

通過兩次調(diào)用具體的timer wait 可以算出具體某一個mutex/sx lock 等待的時間.

如果這個時間再除以每一個線程就可以算出每一個線程在這個Lock 上大概的等待時間, 然后就可以算出平均1s 內(nèi)等在該mutex/sx lock 的占比.

比如我們知道在sysbench oltp_read_write 的小表測試中, 通過pstack 可以看到主要卡在page latch 上, 那么我們需要分析等待patch latch 占用了整個路徑的時間大概是多長.

這里使用256 thread 進(jìn)行壓測, 計算出來等待的時間大概是

buf_block_lock = (122103591705572800-121158362355835200)/5/207/1000000000 = 913ms

也就是平均 1s 里面, 每一個thread 有913ms 等待在page lock 上, 占比90%. 這個信息和多次pstack 的信息也基本吻合.

fil_system_mutex = (3045412747942400-3044314172171200)/5/207 = 1ms

也就是平均1s 里面等待在fil_system_mutex 只有1ms, 占比0.1%

比如我們最常見的 oltp_insert 非 auto_inc insert 的場景中, 通過pstack 可以看到主要卡在trx_sys->mutex, 那么這個trx_sys->mutex 具體有多熱呢?

以下是perf 相關(guān)信息.

上面紅框下主要的熱點都是需要去獲得trx_sys->mutex, 從而可以操作全局活躍事務(wù)數(shù)組.

這里使用256 thread 進(jìn)行壓測, 計算出來等待的時間大概是

trx_sys_mutex =(19702987247840000-19258717650739200)/5/250/1000000000 = 355 ms

那么等待trx_sys->mutex 上占比大概是35%.

上面還有一個看過去大頭的btree 上面的 index_tree_rw_lock 占比呢

index_tree_rw_lock = (471944089179312000-471896220032430400)/5/250/1000000000 = 38ms

雖然數(shù)據(jù)大, 因為跑的久, 但是其實這里只有3% 的占比

tips:

對比來說 perf 看到的信息是on-cpu 信息, 但是因為MySQL 的mutex/sxlock 都是通過backoff 機制進(jìn)行, 在每一次線程切換出去之前都進(jìn)行一段時間的spin, 所以mysql 的on-cpu 信息可以一定程度反應(yīng)off-cpu 的結(jié)果.

pstack 更體現(xiàn)的是某一時刻off-cpu 的信息

performance_schame wait_event 也體現(xiàn)的是off-cpu 的信息.