導(dǎo)讀｜遭受內(nèi)存泄露往往是令開發(fā)者頭疼的問題，傳統(tǒng)分析工具 gdb、Valgrind在解決內(nèi)存泄露問題上效率較低。本文特別邀請到了騰訊后臺開發(fā)工程師邢孟棒以 TDSQL實(shí)際生產(chǎn)中mysql-proxy內(nèi)存泄露問題作為分析對象，分享其基于動態(tài)追蹤技術(shù)的通用內(nèi)存泄露（增長）分析方法。其中將詳細(xì)介紹內(nèi)存分配器行為分析、缺頁異常事件分析，涵蓋應(yīng)用程序內(nèi)存分配的常見過程。閱讀完本文后，開發(fā)者僅需關(guān)注少數(shù)可能導(dǎo)致內(nèi)存泄露的代碼路徑，就能有效提升定位內(nèi)存泄露（增長）問題的效率。

某個 TDSQL 私有化環(huán)境中， 中間件 mysql-proxy 進(jìn)行大量請求轉(zhuǎn)發(fā)時，內(nèi)存占用量持續(xù)增長導(dǎo)致 OOM 現(xiàn)象，最終影響了用戶業(yè)務(wù)的正常使用 。本人分析該問題的過程中發(fā)現(xiàn)一個較為普遍的業(yè)務(wù)痛點(diǎn)：傳統(tǒng)分析工具（gdb、Valgrind 等）效率相對較低，在私有化場景中尤其突出。針對這一痛點(diǎn)，我將提供相對通用的內(nèi)存泄露（增長）分析方法，協(xié)助各位開發(fā)者更高效地定位發(fā)生泄露的代碼路徑，以期最大化減少人力投入成本并降低對用戶業(yè)務(wù)體驗(yàn)的影響。

在展開講述內(nèi)存泄露（增長）分析方法之前，我們先了解一些相關(guān)的基礎(chǔ)概念。
內(nèi)存泄露包括內(nèi)核內(nèi)存泄露、應(yīng)用程序內(nèi)存泄露兩大類。內(nèi)核內(nèi)存泄露可以通過 kmemleak 進(jìn)行檢測，本文主要關(guān)注應(yīng)用程序的內(nèi)存泄露。應(yīng)用程序的內(nèi)存泄露又可以細(xì)分為：堆內(nèi)存（Heap）泄露、內(nèi)存映射區(qū)（Memory Mappings）泄露。我們平時提及的內(nèi)存泄露，主要是指物理內(nèi)存的泄露（持續(xù)分配、映射實(shí)際的物理內(nèi)存，且一直未釋放），危害較大，需要立即修復(fù)。
另外，虛擬內(nèi)存的泄露（持續(xù)分配虛擬內(nèi)存，但未分配、映射實(shí)際的物理內(nèi)存）容易被忽視，雖然危害相對較小，但也需額外關(guān)注（進(jìn)程的內(nèi)存映射區(qū)總數(shù)量有上限，默認(rèn) 1w）。
通常，應(yīng)用程序內(nèi)存分配涉及的步驟大致如下圖所示：第一，應(yīng)用程序通過內(nèi)存分配器（例如 libc）提供的 malloc 及其變體函數(shù)申請內(nèi)存，free 函數(shù)釋放相應(yīng)內(nèi)存。第二，內(nèi)存分配器（例如 libc）內(nèi)部通過系統(tǒng)調(diào)用 brk 擴(kuò)展堆內(nèi)存（小塊內(nèi)存分配）。第三，內(nèi)存分配器（例如 libc）內(nèi)部通過系統(tǒng)調(diào)用 mmap 分配內(nèi)存映射區(qū)域（大塊內(nèi)存分配，默認(rèn)不小于 128 KB）第四，二或三已申請的虛擬內(nèi)存在首次寫入時觸發(fā)缺頁異常，OS 分配實(shí)際物理頁面，并將虛擬內(nèi)存與其相關(guān)聯(lián)，記錄至頁表。
其中，步驟一至三均為虛擬內(nèi)存，步驟四分配實(shí)際物理內(nèi)存并創(chuàng)建相應(yīng)頁表。

傳統(tǒng)分析工具 gdb、Valgrind

在定位 mysql-proxy 內(nèi)存泄露（增長）問題的過程中，開發(fā)人員嘗試使用了 Valgrind Memcheck、gdb 進(jìn)行協(xié)助分析。最終前者實(shí)際效果不太理想；我通過后者分析出泄露原因，但整個過程耗費(fèi)了較多時間。
gdb 是常用的程序調(diào)試工具，好處不用贅述。但對于內(nèi)存泄露或增長問題，gdb 缺點(diǎn)也較為明顯，大致如下：干擾程序正常運(yùn)行，不適合生產(chǎn)環(huán)境；直接定位比較困難，且要求對源碼有一定了解。
Valgrind Memcheck 是一款知名度較高的內(nèi)存泄露分析工具，非常強(qiáng)大，開發(fā)調(diào)試過程中能夠快速發(fā)現(xiàn)場景的內(nèi)存泄露問題。不過開發(fā)者在使用之前，建議對以下情況有所了解：第一，需要重啟程序，且作為 Valgrind 子進(jìn)程運(yùn)行。不適合分析正在發(fā)生內(nèi)存增長的進(jìn)程。第二，替代默認(rèn)的 malloc/free 等分配函數(shù)，目標(biāo)進(jìn)程運(yùn)行速度減慢 20~30 倍。第三，不能很好的支持 tcmalloc、jemalloc 內(nèi)存分配器。（mysql-proxy 采用了 jemalloc 內(nèi)存分配器）

基于動態(tài)追蹤的通用分析方法

對于正在運(yùn)行、內(nèi)存持續(xù)增長的應(yīng)用來說，gdb、Valgrind Memcheck 工具其實(shí)都挺難發(fā)揮價值。相比而言，動態(tài)追蹤技術(shù)提供了一種通用且易用的方式。內(nèi)存分配器相關(guān)函數(shù)調(diào)用、系統(tǒng)調(diào)用、缺頁異常等，都可以看作一個個事件。通過對這些事件的追蹤、統(tǒng)計(jì)等，我們可以分析有關(guān)內(nèi)存使用情況的具體代碼路徑，在不深入源碼細(xì)節(jié)的前提下快速縮小泄露發(fā)生的范圍。
本文涉及兩種基于動態(tài)追蹤的通用分析方法：內(nèi)存分配器行為分析、缺頁異常事件分析，涵蓋應(yīng)用程序內(nèi)存分配的常見過程。

1）內(nèi)存分配器行為分析

內(nèi)存分配器（glibc、jemalloc 等）行為分析整體思路如下：首先，站在應(yīng)用視角，重點(diǎn)關(guān)注應(yīng)用程序內(nèi)存分配的代碼路徑。其次，動態(tài)追蹤內(nèi)存分配相關(guān)函數(shù)，統(tǒng)計(jì)未釋放內(nèi)存分配的調(diào)用棧與總字節(jié)數(shù)量，形成分析工具 memstacks。

• 開發(fā)新工具 memstacks

該工具支持生成兩種類型的火焰圖：一種是僅追蹤 malloc 及其變體函數(shù)，不做 free 抵消，結(jié)果可用于生成全量內(nèi)存分配火焰圖。另一種是追蹤 malloc 及其變體函數(shù)、free 函數(shù)，計(jì)算出追蹤期間未釋放的內(nèi)存分配，結(jié)果可用于生成未釋放內(nèi)存分配火焰圖。
其實(shí)現(xiàn)原理大致如下：借鑒現(xiàn)有 BCC 工具 memleak、mallocstacks，支持生成折疊棧，可生成全量內(nèi)存分配火焰圖、未釋放內(nèi)存分配火焰圖。借助 uprobes 動態(tài)追蹤 malloc（以及變體 cmalloc、realloc）、free。?

如上圖所示，現(xiàn)有 BCC 工具 memleak、mallocstacks 各有優(yōu)劣。新工具 memstacks 結(jié)合兩者優(yōu)點(diǎn)，允許有選擇性的生成全量內(nèi)存分配火焰圖或者未釋放內(nèi)存分配火焰圖需要的折疊棧格式。

• 全量內(nèi)存分配火焰圖

執(zhí)行以下命令，追蹤 mysql-proxy 進(jìn)程所有 malloc 及其變體調(diào)用 60s，并生成全量內(nèi)存分配火焰圖。

火焰圖如下所示，可以協(xié)助開發(fā)者理解 mysql-proxy 調(diào)用 malloc 及其變體的關(guān)鍵代碼路徑。

【文章福利】小編推薦自己的Linux內(nèi)核技術(shù)交流群:【749907784】整理了一些個人覺得比較好的學(xué)習(xí)書籍、視頻資料共享在群文件里面，有需要的可以自行添加哦?。。。ê曨l教程、電子書、實(shí)戰(zhàn)項(xiàng)目及代碼)? ? ??

• 未釋放內(nèi)存分配火焰圖

執(zhí)行以下命令，追蹤 mysql-proxy 進(jìn)程未釋放 malloc 及其變體調(diào)用 60s，并生成內(nèi)存分配火焰圖。

火焰圖如下所示，其中：未釋放內(nèi)存共計(jì) 27.75 MB（追蹤期間，通過 pidstat 觀察到 mysql-proxy 進(jìn)程 RSS 增量接近 27 MB，與未釋放內(nèi)存統(tǒng)計(jì)量 27.75 MB 基本一致）。
已分配但未釋放的代碼路徑主要有兩處。其中，據(jù)研發(fā)反饋，tdsql::Item_param::set_str 正是導(dǎo)致 mysql-proxy 內(nèi)存泄露發(fā)生的地方。而另一處并非真正的泄露。該工具有一定的副作用，由于追蹤的最后階段有一些剛分配的內(nèi)存還未來得及釋放，需要進(jìn)一步閱讀源碼甄別。另外，建議多運(yùn)行幾次對比下結(jié)果，排除那些經(jīng)常變化的分配路徑。

對已分配但未釋放的代碼路徑展開，結(jié)果如下：

相比全量內(nèi)存分配火焰圖，數(shù)據(jù)量減少近 60 倍，需要重點(diǎn)關(guān)注的代碼路徑的減少也比較明顯。因此，推薦優(yōu)先使用未釋放內(nèi)存分配火焰圖進(jìn)行分析。

2）缺頁異常事件分析

相比內(nèi)存分配器行為分析，缺頁異常事件分析提供了另一種視角，整體思路如下：首先，站在內(nèi)核視角，關(guān)注的是首次寫入觸發(fā)缺頁異常的代碼路徑，而不是觸發(fā)內(nèi)存分配的代碼路徑。前者是進(jìn)程 RSS增長的原因，后者僅分配了虛擬內(nèi)存，尚未映射物理內(nèi)存。其次，追蹤缺頁異常事件，統(tǒng)計(jì)未釋放物理內(nèi)存的調(diào)用棧與總頁面數(shù)量，形成分析工具 pgfaultstacks。

• 現(xiàn)有分析工具

傳統(tǒng)工具 perf，基于軟件事件 page-faults

BCC 工具 stackcount

基于靜態(tài)追蹤點(diǎn) exceptions:page_fault_user。

現(xiàn)有分析工具雖然方便，但是以增量的方式去統(tǒng)計(jì)，不考慮追蹤過程中被釋放的物理內(nèi)存，最終統(tǒng)計(jì)的結(jié)果通常會偏大，對內(nèi)存泄露（增長）的分析會造成干擾。

• 缺頁異?；鹧鎴D（現(xiàn)有版）

執(zhí)行以下命令，追蹤 mysql-proxy 進(jìn)程所有缺頁事件 60s，并生成缺頁異?；鹧鎴D。

火焰圖具體如下，共計(jì) 420,342 次缺頁事件，但不是每一次缺頁事件都分配一個新的物理頁面（大多數(shù)情況下未分配），mysql-proxy RSS 實(shí)際增長量僅 60 多MB 。

• 開發(fā)新工具 pgfaultstacks

該工具的實(shí)現(xiàn)原理大致如下：第一，改進(jìn)現(xiàn)有缺頁事件統(tǒng)計(jì)方式（過濾物理頁面已存在的缺頁事件，并在追蹤完成后讀取目標(biāo)進(jìn)程的內(nèi)存映射列表，通過計(jì)算將已釋放的物理頁面排除在外），僅關(guān)注真正泄露的物理內(nèi)存。
第二，借助 tracepoint 或 kprobe 動態(tài)追蹤 page faults 事件，一般情況下性能開銷可忽略不計(jì)。

• 缺頁異?；鹧鎴D

執(zhí)行以下命令，追蹤 mysql-proxy 進(jìn)程滿足過濾條件的缺頁事件 60s，并生成缺頁火焰圖。

缺頁火焰圖如下，其中：共計(jì)增加 17801 個物理頁面（與 mysql-proxy 進(jìn)程 RSS 增量基本一致）。重點(diǎn)關(guān)注函數(shù) g_string_append_printf。（注：非內(nèi)存泄露發(fā)生的環(huán)境，僅用來演示缺頁異?；鹧鎴D）

相比現(xiàn)有版，該版本的數(shù)據(jù)量減少 20 多倍，需要重點(diǎn)關(guān)注的代碼路徑減少也比較明顯。

總結(jié)

本文以 TDSQL 實(shí)際生產(chǎn)中 mysql-proxy 內(nèi)存泄露問題作為分析對象，探索基于動態(tài)追蹤技術(shù)的通用內(nèi)存泄露（增長）分析方法：內(nèi)存分配器行為分析、缺頁異常事件分析，并針對現(xiàn)有分析工具進(jìn)行改進(jìn)，形成相應(yīng)的分析工具 memstacks、pgfaultstacks，歡迎各位開發(fā)者嘗試去開發(fā)。工具使用者僅需關(guān)注少數(shù)可能導(dǎo)致內(nèi)存泄露的代碼路徑，有效提升定位內(nèi)存泄露（增長）問題的效率。如果你正在遭受內(nèi)存泄露（增加）的困擾，不妨下載使用最新版 OpenCloudOS，嘗試本文提及的分析方法和工具。

原文作者：騰訊云開發(fā)者