本文分享自華為雲社群《【華為雲MySQL技術專欄】MySQL記憶體增長問題分析案例》，作者：GaussDB 資料庫。
前言
在現網環境中，偶爾會遇到客戶例項記憶體OOM（Out Of Memory，即記憶體耗盡或溢位）的情況。MySQL資料庫作為一款面向高併發應用場景的系統軟體，因其應用場景複雜且函式呼叫鏈極長，導致分析記憶體異常問題變得非常困難。
MySQL提供了Performance Schema功能，用於跟蹤其效能指標，包括記憶體佔用情況。但該工具是有一定的侷限性，只能監控透過MySQL提供的記憶體分配介面分配的記憶體，不能監控直接使用malloc或者new函式分配的記憶體。這種情況我們就可以藉助jeprof工具（jeprof是jemalloc配套的記憶體分析工具）來定位，以下是藉助jeprof定位MySQL記憶體問題的分析過程。
問題描述
在生產環境中，某客戶的例項頻繁出現OOM，透過排查客戶業務，發現是大事務導致的記憶體異常增長，該例項的MySQL版本為8.0.22（MySQL 8.0.25以後的版本解決了記憶體異常增長問題），我們透過如下方式在本地進行復現：
1. 採用sysbench往一張表中壓入100000000條資料，如下：
sysbench --mysql-host=xxx --mysql-port=xxx --mysql-user=xxx --mysql-password=xxx \/usr/share/sysbench/oltp_read_write.lua --tables=1 \--table_size=100000000 prepare
begin; update sbtest1 set k=k+1;
該語句執行前，透過top命令檢視到的記憶體使用情況如下：
語句執行過程中，記憶體持續增長，執行完畢時，其記憶體佔用如下：
執行過程中，實體記憶體增長了近2.6g，顯然佔用異常，若併發量較大的情況下，勢必會OOM。
定位過程
1. 檢視performance_schema相關的記憶體監控資料
遇到MySQL的記憶體問題，首先想到的是開啟performance_schema開啟MySQL自帶的記憶體監控，這些監控在相當一部分場景下的確發揮了重要作用。
例如，可以使用如下的命令檢視記憶體情況：
select event_name, current_alloc from sys.memory_global_by_current_bytes limit 20;
但performance_schema監控資料也有一些侷限性。比如當前的這個場景，MySQL自帶的記憶體監控並沒有取樣到任何的記憶體變化。這是因為自帶的記憶體監控只能監控到透過MySQL記憶體分配函式分配的記憶體，比如以mem_block_info_t為單位的MySQL記憶體分配函式等。所以，直接透過malloc或者new分配的函式，自帶記憶體監控是無法監控到的。
jeprof可以捕獲所有的malloc和free函式的呼叫，不過由於glibc預設的分配器是ptmalloc，因此，需要一些配置將預設的ptmalloc替換成jemalloc。
下載jemalloc原始碼，啟用--enable-prof，編譯出對應的libjemalloc.so.2，jeprof工具即可，具體如下：
步驟一：下載jemalloc原始碼，進入解壓後的目錄，執行如下命令編譯出對應的libjemalloc.so.2，jeprof工具；
cd {jemalloc解壓後的目錄} ./autogen.sh --enable-prof ./configure --enable-prof
export MALLOC_CONF="background_thread:true,narenas:4,dirty_decay_ms:5000,prof:true,prof_prefix:/opt/workdir/logs/log,lg_prof_interval:30,lg_prof_sample:19"
export LD_PRELOAD='/jemalloc/libjemalloc.so.2' // 步驟一編譯出來的libjemalloc.so.2路徑
結果分析
關於jeprof結果解析的命令，這裡不再贅述，具體可以透過jeprof -h檢視。
就本文的問題而言，實際上只需要關心從語句執行開始到語句執行結束記憶體的變化部分就可。那麼，就可以透過如下命令對比第一次生成的profing資料以及最後一次的profling資料：
/jemalloc/jeprof --pdf ./mysqld --base=log.start.heap log.end.heap > ../xxx.pdf
這裡取部分結果的截圖做分析:
void Rpl_transaction_write_set_ctx::add_write_set(uint64 hash) { DBUG_TRACE; DBUG_EXECUTE_IF("add_write_set_crash_no_memory", throw std::bad_alloc();); write_set.push_back(hash); }
參考《STL原始碼剖析》一書, vector的底層資料結構其實就是一段連續的線性空間，以start指標和fininsh指標分別指向已申請的連續空間中目前已被使用的範圍，以end_of_storage指標指向連續空間的尾端，當原空間使用完，也即fininsh==end_of_storage時，vector會執行的動態擴容，也就是_M_realloc_insert過程, 其步驟如下：
而write_set恰是一個vector, 因此可以確定write_set佔用了3072M記憶體從而導致記憶體的異常增長。這其實也是vector錯誤使用的一個典型案例，對於這種大量的push_back場景，由於vector的2倍擴容，不僅會導致記憶體佔用過多，擴容的過程中反覆的申請新記憶體、釋放舊記憶體也會導致效能問題。若僅考慮當前的問題場景，顯然list是更優的選擇。
注意事項
1. 編譯jemalloc時，注意./autogen.sh --enable-prof 以及./configure --enable-prof 都需要加上--enable-prof選項，若僅在./autogen.sh是加上--enable-prof引數，這種情況下你需要在啟動的時候以如下方式啟動mysqld, 否則無法生成profiling檔案：
LD_PRELOAD='/jemalloc/libjemalloc.so.2' bin/mysqld &
2. 注意MALLOC_CONF的引數中lg_prof_interval引數。該引數設定過小，會嚴重影響mysqld的效能。當執行效能下降後，某些場景可能就不會復現。比如本文所涉及的問題場景，lg_prof_interval設定的過小，就幾乎觀察不到明顯的記憶體變化。
3. 透過jeprof取樣到的資料沒有捕獲到buffer pool的記憶體分配，這是因為jeprof是透過在jemalloc中設定取樣點來採集資料的，只有應用程式透過malloc, free分配釋放記憶體才會被採集到，而MySQL的buffer pool記憶體是直接透過mmap系統呼叫分配的，不經過jemalloc, 可以參考MySQL的large_page_aligned_alloc函式，所有的大記憶體均是透過該函式分配的。
inline void *large_page_aligned_alloc(size_t n_bytes) { int mmap_flags = MAP_PRIVATE | MAP_ANON; void *ptr = mmap(nullptr, n_bytes, PROT_READ | PROT_WRITE, mmap_flags, -1, 0); return (ptr != (void *)-1) ? ptr : nullptr; }
總結
上述客戶業務中出現的問題，歸根結底是程式碼中未對vector的記憶體進行限制，才有了大事務場景下記憶體無限增長最終導致OOM發生。華為雲RDS for MySQL和GaussDB(for MySQL)完全相容MySQL，華為雲資料庫在產品中對該問題進行了提前修復，後來開源MySQL在高版本中也對該問題也進行了修復。因此，MySQL記憶體問題可以結合MySQL提供的performance schema記憶體表和jeprof工具來輔助定位。
HDC 2024，6月21日-23日，東莞松山湖，期待與您相見！
更多詳情請參見大會官網：
中文：https://developer.huawei.com/home/hdc
英文：https://developer.huawei.com/home/en/hdc
點選關注，第一時間瞭解華為雲新鮮技術~