告別記憶體OOM，解決MySQL記憶體增長問題

本文分享自華為雲社區《【華為雲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

點擊關註，第一時間瞭解華為雲新鮮技術~