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

所以我們需要一個定量分析系統瓶頸的方法以便于我們進行系統優化.

本文通過Performance_schema 來進行定量的分析系統性能瓶頸.

原理如下:

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

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

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

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

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

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 相關信息.

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

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

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

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

tips:

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

pstack 更體現的是某一時刻off-cpu 的信息

performance_schame wait_event 也體現的是off-cpu 的信息.