mysql數(shù)據(jù)比較，mysql數(shù)據(jù)庫(kù)cpu飆升800？

mysql中CPU占用過高的診斷思路，舉個(gè)栗子~

mpstat -P ALL 1，查看cpu使用情況，主要消耗在sys即os系統(tǒng)調(diào)用上

perf top，cpu主要消耗在_spin_lock

生成perf report查看詳細(xì)情況

CPU主要消耗在mutex爭(zhēng)用上，說明有鎖熱點(diǎn)。

采用pt-pmp跟蹤mysqld執(zhí)行情況，熱點(diǎn)主要集中在mem_heap_alloc和mem_heap_free上。

Pstack提供更詳細(xì)的API調(diào)用棧

#0 0x0000003e0caf80cf in __lll_unlock_wake_private () from /lib64/libc.so.6#1 0x0000003e0ca7cf6a in _L_unlock_5936 () from /lib64/libc.so.6#2 0x0000003e0ca78bbc in _int_free () from /lib64/libc.so.6#3 0x000000000097dcb3 in mem_area_free(void*, mem_pool_t*) ()#4 0x000000000097d2d2 in mem_heap_block_free(mem_block_info_t*, mem_block_info_t*) ()#5 0x00000000009e6474 in row_vers_build_for_consistent_read(unsigned char const*, mtr_t*, dict_index_t*, unsigned long**, read_view_t*, mem_block_info_t**, mem_block_info_t*, unsigned char**) ()#6 0x00000000009dce75 in row_search_for_mysql(unsigned char*, unsigned long, row_prebuilt_t*, unsigned long, unsigned long) ()#7 0x0000000000939c95 in ha_innobase::index_read(unsigned char*, unsigned char const*, unsigned int, ha_rkey_function) ()

Innodb在讀取數(shù)據(jù)記錄時(shí)的API路徑為

row_search_for_mysql --》row_vers_build_for_consistent_read --》mem_heap_create_block_func --》mem_area_alloc --》malloc --》_L_unlock_10151 --》__lll_unlock_wait_private

row_vers_build_for_consistent_read會(huì)陷入一個(gè)死循環(huán)，跳出條件是該條記錄不需要快照讀或者已經(jīng)從undo中找出對(duì)應(yīng)的快照版本，每次循環(huán)都會(huì)調(diào)用mem_heap_alloc/free。

而該表的記錄更改很頻繁，導(dǎo)致其undo history list比較長(zhǎng)，搜索快照版本的代價(jià)更大，就會(huì)頻繁的申請(qǐng)和釋放堆內(nèi)存。

Linux原生的內(nèi)存庫(kù)函數(shù)為ptmalloc，malloc/free調(diào)用過多時(shí)很容易產(chǎn)生鎖熱點(diǎn)。

當(dāng)多條 SQL 并發(fā)執(zhí)行時(shí)，會(huì)最終觸發(fā)os層面的spinlock，導(dǎo)致上述情形。

解決方案

將mysqld的內(nèi)存庫(kù)函數(shù)替換成tcmalloc，相比ptmalloc，tcmalloc可以更好的支持高并發(fā)調(diào)用。

修改my.cnf，添加如下參數(shù)并重啟

[mysqld_safe]malloc-lib=tcmalloc

上周五早上7點(diǎn)執(zhí)行的操作，到現(xiàn)在超過72小時(shí)，期間該實(shí)例沒有再出現(xiàn)cpu長(zhǎng)期飆高的情形。

以下是修改前后cpu使用率對(duì)比