導讀｜遭受內存泄露往往是令開發者頭疼的問題，傳統分析工具 gdb、Valgrind在解決內存泄露問題上效率較低。本文特別邀請到了騰訊後臺開發工程師邢孟棒以 TDSQL實際生產中mysql-proxy內存泄露問題作爲分析對象，分享其基於動態追蹤技術的通用內存泄露（增長）分析方法。其中將詳細介紹內存分配器行爲分析、缺頁異常事件分析，涵蓋應用程序內存分配的常見過程。閱讀完本文後，開發者僅需關注少數可能導致內存泄露的代碼路徑，就能有效提升定位內存泄露（增長）問題的效率。
背景
某個 TDSQL 私有化環境中， 中間件 mysql-proxy 進行大量請求轉發時，內存佔用量持續增長導致 OOM 現象，最終影響了用戶業務的正常使用 。本人分析該問題的過程中發現一個較爲普遍的業務痛點：傳統分析工具（gdb、Valgrind 等）效率相對較低，在私有化場景中尤其突出。針對這一痛點，我將提供相對通用的內存泄露（增長）分析方法，協助各位開發者更高效地定位發生泄露的代碼路徑，以期最大化減少人力投入成本並降低對用戶業務體驗的影響。
基礎概念
在展開講述內存泄露（增長）分析方法之前，我們先了解一些相關的基礎概念。
內存泄露包括內核內存泄露、應用程序內存泄露兩大類。內核內存泄露可以通過 kmemleak 進行檢測，本文主要關注應用程序的內存泄露。應用程序的內存泄露又可以細分爲：堆內存（Heap）泄露、內存映射區（Memory Mappings）泄露。我們平時提及的內存泄露，主要是指物理內存的泄露（持續分配、映射實際的物理內存，且一直未釋放），危害較大，需要立即修復。
另外，虛擬內存的泄露（持續分配虛擬內存，但未分配、映射實際的物理內存）容易被忽視，雖然危害相對較小，但也需額外關注（進程的內存映射區總數量有上限，默認 1w）。
通常，應用程序內存分配涉及的步驟大致如下圖所示：
第一，應用程序通過內存分配器（例如 libc）提供的 malloc 及其變體函數申請內存，free 函數釋放相應內存。第二，內存分配器（例如 libc）內部通過系統調用 brk 擴展堆內存（小塊內存分配）。第三，內存分配器（例如 libc）內部通過系統調用 mmap 分配內存映射區域（大塊內存分配，默認不小於 128 KB）第四，二或三已申請的虛擬內存在首次寫入時觸發缺頁異常，OS 分配實際物理頁面，並將虛擬內存與其相關聯，記錄至頁表。
其中，步驟一至三均爲虛擬內存，步驟四分配實際物理內存並創建相應頁表。
傳統分析工具 gdb、Valgrind
在定位 mysql-proxy 內存泄露（增長）問題的過程中，開發人員嘗試使用了 Valgrind Memcheck、gdb 進行協助分析。最終前者實際效果不太理想；我通過後者分析出泄露原因，但整個過程耗費了較多時間。
gdb 是常用的程序調試工具，好處不用贅述。但對於內存泄露或增長問題，gdb 缺點也較爲明顯，大致如下：干擾程序正常運行，不適合生產環境直接定位比較困難，且要求對源碼有一定了解。
Valgrind Memcheck 是一款知名度較高的內存泄露分析工具，非常強大，開發調試過程中能夠快速發現場景的內存泄露問題。不過開發者在使用之前，建議對以下情況有所瞭解：
第一，需要重啓程序，且作爲 Valgrind 子進程運行。不適合分析正在發生內存增長的進程。
第二，替代默認的 malloc/free 等分配函數，目標進程運行速度減慢 20~30 倍。
第三，不能很好的支持 tcmalloc、jemalloc 內存分配器。（mysql-proxy 採用了 jemalloc 內存分配器）
基於動態追蹤的通用分析方法
對於正在運行、內存持續增長的應用來說，gdb、Valgrind Memcheck 工具其實都挺難發揮價值。相比而言，動態追蹤技術提供了一種通用且易用的方式。內存分配器相關函數調用、系統調用、缺頁異常等，都可以看作一個個事件。通過對這些事件的追蹤、統計等，我們可以分析有關內存使用情況的具體代碼路徑，在不深入源碼細節的前提下快速縮小泄露發生的範圍。
本文涉及兩種基於動態追蹤的通用分析方法：內存分配器行爲分析、缺頁異常事件分析，涵蓋應用程序內存分配的常見過程。
1）內存分配器行爲分析
內存分配器（glibc、jemalloc 等）行爲分析整體思路如下：
首先，站在應用視角，重點關注應用程序內存分配的代碼路徑。
其次，動態追蹤內存分配相關函數，統計未釋放內存分配的調用棧與總字節數量，形成分析工具 memstacks。
-
開發新工具 memstacks
該工具支持生成兩種類型的火焰圖：
一種是僅追蹤 malloc 及其變體函數，不做 free 抵消，結果可用於生成全量內存分配火焰圖。
另一種是追蹤 malloc 及其變體函數、free 函數，計算出追蹤期間未釋放的內存分配，結果可用於生成未釋放內存分配火焰圖。
其實現原理大致如下：
借鑑現有 BCC 工具 memleak、mallocstacks，支持生成摺疊棧，可生成全量內存分配火焰圖、未釋放內存分配火焰圖。
藉助 uprobes 動態追蹤 malloc（以及變體 cmalloc、realloc）、free。
如上圖所示，現有 BCC 工具 memleak、mallocstacks 各有優劣。新工具 memstacks 結合兩者優點，允許有選擇性的生成全量內存分配火焰圖或者未釋放內存分配火焰圖需要的摺疊棧格式。
-
全量內存分配火焰圖
執行以下命令，追蹤 mysql-proxy 進程所有 malloc 及其變體調用 60s，並生成全量內存分配火焰圖。
# 步驟 1. 追蹤 60s，生成全量內存分配摺疊棧
# 其中，參數 -a 表示追蹤所有的 malloc 及其變體，但不追蹤 free 進行相互抵消。參數 -f 表示生成摺疊棧，用於步驟 2 生成火焰圖。./memstacks -p $(pgrep -nx mysql-proxy) -af 60 > all_mallocs.stacks
# 步驟 2. 執行下述命令生成全量內存分配火焰圖，輸出至文件 all_mallocs.svg。./flamegraph.pl --color=mem --title="All malloc() bytes Flame Graph" --countname="bytes" < all_mallocs.stacks > all_mallocs.svg
火焰圖如下所示，可以協助開發者理解 mysql-proxy 調用 malloc 及其變體的關鍵代碼路徑。
-
未釋放內存分配火焰圖
執行以下命令，追蹤 mysql-proxy 進程未釋放 malloc 及其變體調用 60s，並生成內存分配火焰圖。
# 步驟 1. 追蹤 60s，生成未釋放內存分配摺疊棧
# 其中，參數 -f 表示生成摺疊棧，用於步驟 2 生成火焰圖。memstacks -p $(pgrep -nx mysql-proxy) -f 60 > unfreed_mallocs.stacks
# 步驟 2. 執行下述命令生成未釋放內存分配火焰圖，輸出到文件 unfreed_mallocs.svg。./flamegraph.pl --color=mem --title="Unfreed malloc() bytes Flame Graph" --countname="bytes" < unfreed_mallocs.stacks > unfreed_mallocs.svg
火焰圖如下所示，其中：
未釋放內存共計 27.75 MB（追蹤期間，通過 pidstat 觀察到 mysql-proxy 進程 RSS 增量接近 27 MB，與未釋放內存統計量 27.75 MB 基本一致）。
已分配但未釋放的代碼路徑主要有兩處。其中，據研發反饋，tdsql::Item_param::set_str 正是導致 mysql-proxy 內存泄露發生的地方。而另一處並非真正的泄露。該工具有一定的副作用，由於追蹤的最後階段有一些剛分配的內存還未來得及釋放，需要進一步閱讀源碼甄別。另外，建議多運行幾次對比下結果，排除那些經常變化的分配路徑。
對已分配但未釋放的代碼路徑展開，結果如下：
相比全量內存分配火焰圖，數據量減少近 60 倍，需要重點關注的代碼路徑的減少也比較明顯。因此，推薦優先使用未釋放內存分配火焰圖進行分析。
2）缺頁異常事件分析
相比內存分配器行爲分析，缺頁異常事件分析提供了另一種視角，整體思路如下：
首先，站在內核視角，關注的是首次寫入觸發缺頁異常的代碼路徑，而不是觸發內存分配的代碼路徑。前者是進程 RSS增長的原因，後者僅分配了虛擬內存，尚未映射物理內存。
其次，追蹤缺頁異常事件，統計未釋放物理內存的調用棧與總頁面數量，形成分析工具 pgfaultstacks。
-
現有分析工具
傳統工具 perf，基於軟件事件 page-faults
perf record -p $(pgrep -nx mysql-proxy) -e page-faults -c 1 -g -- sleep 60
BCC 工具 stackcount
基於靜態追蹤點 exceptions:page_fault_user。
stackcount -p $(pgrep -nx mysql-proxy) -U t:exceptions:page_fault_user
現有分析工具雖然方便，但是以增量的方式去統計，不考慮追蹤過程中被釋放的物理內存，最終統計的結果通常會偏大，對內存泄露（增長）的分析會造成干擾。
-
缺頁異常火焰圖（現有版）
執行以下命令，追蹤 mysql-proxy 進程所有缺頁事件 60s，並生成缺頁異常火焰圖。
perf record -p $(pgrep -nx mysql-proxy) -e page-faults -c 1 -g -- sleep 60 > pgfault.stacks
./flamegraph.pl --color=mem --title="Page Fault Flame Graph" --countname="pages" < pgfault.stacks > pgfault.svg
火焰圖具體如下，共計 420,342 次缺頁事件，但不是每一次缺頁事件都分配一個新的物理頁面（大多數情況下未分配），mysql-proxy RSS 實際增長量僅 60 多MB 。
-
開發新工具 pgfaultstacks
該工具的實現原理大致如下：
第一，改進現有缺頁事件統計方式（過濾物理頁面已存在的缺頁事件，並在追蹤完成後讀取目標進程的內存映射列表，通過計算將已釋放的物理頁面排除在外），僅關注真正泄露的物理內存。
第二，藉助 tracepoint 或 kprobe 動態追蹤 page faults 事件，一般情況下性能開銷可忽略不計。
-
缺頁異常火焰圖
執行以下命令，追蹤 mysql-proxy 進程滿足過濾條件的缺頁事件 60s，並生成缺頁火焰圖。
# 步驟 1. 追蹤 60s，生成缺頁異常摺疊棧。其中，參數 -f 表示生成摺疊棧，用於步驟 2 生成火焰圖。pgfaultstacks -p $(pgrep -nx mysql-proxy) -f 60 > pgfault.stacks
# 步驟 2. 生成缺頁火焰圖，輸出到文件 pgfault.svg。./flamegraph.pl --color=mem --title="Page Fault Flame Graph" --countname="pages" < pgfault.stacks > pgfault.svg
缺頁火焰圖如下，其中：
共計增加 17801 個物理頁面（與 mysql-proxy 進程 RSS 增量基本一致）。
重點關注函數 g_string_append_printf。（注：非內存泄露發生的環境，僅用來演示缺頁異常火焰圖）
相比現有版，該版本的數據量減少 20 多倍，需要重點關注的代碼路徑減少也比較明顯。
總結
本文以 TDSQL 實際生產中 mysql-proxy 內存泄露問題作爲分析對象，探索基於動態追蹤技術的通用內存泄露（增長）分析方法：內存分配器行爲分析、缺頁異常事件分析，並針對現有分析工具進行改進，形成相應的分析工具 memstacks、pgfaultstacks，歡迎各位開發者嘗試去開發。工具使用者僅需關注少數可能導致內存泄露的代碼路徑，有效提升定位內存泄露（增長）問題的效率。如果你正在遭受內存泄露（增加）的困擾，不妨嘗試下本文提及的分析方法和工具，希望有所幫助。
騰訊工程師技術乾貨直達：