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

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

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

原理如下:

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

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

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

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

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

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

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

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

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

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

比如我們最常見(jiàn)的 oltp_insert 非 auto_inc insert 的場(chǎng)景中, 通過(guò)pstack 可以看到主要卡在trx_sys->mutex, 那么這個(gè)trx_sys->mutex 具體有多熱呢?

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

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

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

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

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

上面還有一個(gè)看過(guò)去大頭的btree 上面的 index_tree_rw_lock 占比呢

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

雖然數(shù)據(jù)大, 因?yàn)榕艿木? 但是其實(shí)這里只有3% 的占比

tips:

對(duì)比來(lái)說(shuō) perf 看到的信息是on-cpu 信息, 但是因?yàn)镸ySQL 的mutex/sxlock 都是通過(guò)backoff 機(jī)制進(jìn)行, 在每一次線(xiàn)程切換出去之前都進(jìn)行一段時(shí)間的spin, 所以mysql 的on-cpu 信息可以一定程度反應(yīng)off-cpu 的結(jié)果.

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

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