导读|遭受内存泄露往往是令开发者头疼的问题,传统分析工具 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
-
全量内存分配火焰图
# 步骤 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 及其变体的关键代码路径。
-
未释放内存分配火焰图
# 步骤 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::set_str 正是导致 mysql-proxy 内存泄露发生的地方。而另一处并非真正的泄露。该工具有一定的副作用,由于追踪的最后阶段有一些刚分配的内存还未来得及释放,需要进一步阅读源码甄别。另外,建议多运行几次对比下结果,排除那些经常变化的分配路径。
对已分配但未释放的代码路径展开,结果如下:相比全量内存分配火焰图,数据量减少近 60 倍,需要重点关注的代码路径的减少也比较明显。因此,推荐优先使用未释放内存分配火焰图进行分析。
2)缺页异常事件分析
相比内存分配器行为分析,缺页异常事件分析提供了另一种视角,整体思路如下:首先,站在内核视角,关注的是首次写入触发缺页异常的代码路径,而不是触发内存分配的代码路径。前者是进程 RSS增长的原因,后者仅分配了虚拟内存,尚未映射物理内存。其次,追踪缺页异常事件,统计未释放物理内存的调用栈与总页面数量,形成分析工具 pgfaultstacks。-
现有分析工具
perfrecord-p$(pgrep-nxmysql-proxy)-epage-faults-c1-g--sleep60
BCC 工具 stackcount基于静态追踪点 exceptions:page_fault_user。
stackcount -p $(pgrep -nx mysql-proxy) -U tpage_fault_user
现有分析工具虽然方便,但是以增量的方式去统计,不考虑追踪过程中被释放的物理内存,最终统计的结果通常会偏大,对内存泄露(增长)的分析会造成干扰。
-
缺页异常火焰图(现有版)
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
-
缺页异常火焰图
# 步骤 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,欢迎各位开发者尝试去开发。工具使用者仅需关注少数可能导致内存泄露的代码路径,有效提升定位内存泄露(增长)问题的效率。如果你正在遭受内存泄露(增加)的困扰,不妨尝试下本文提及的分析方法和工具,希望有所帮助。 审核编辑 :李倩
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。
举报投诉
-
内存
+关注
关注
8文章
2804浏览量
73142 -
代码
+关注
关注
30文章
4603浏览量
67389 -
应用程序
+关注
关注
37文章
3172浏览量
57099
原文标题:邢孟棒:2个压箱底的方法和工具搞定内存泄漏
文章出处:【微信号:LinuxDev,微信公众号:Linux阅码场】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
【鸿蒙】webview内存泄漏问题的分析报告
1 关键字 webview;内存泄漏 2 问题描述 问题现象:在 3.1release 版本和 3.2bete1 版本中,在 RK3568 上使用 etsWeb 和其他浏览器时,webview 所占
内存溢出与内存泄漏:定义、区别与解决方案
与区别 1. 定义: 内存溢出(Memory Overflow)指的是程序在申请内存时,无法获得足够的内存空间,导致程序抛出异常或崩溃。当程序需要的内存超过了当前可用的
jvm内存分析命令和工具
JVM内存分析是Java开发和调优过程中非常重要的一部分。通过对JVM内存分析命令和工具的深入了解和使用,可以帮助开发人员识别内存泄漏、性能
什么是内存泄漏?如何避免JavaScript内存泄漏
JavaScript 代码中常见的内存泄漏的常见来源: 研究内存泄漏问题就相当于寻找符合垃圾回收机制的编程方式,有效避免对象引用的问题。
发表于 10-27 11:30
•185次阅读
高级内存调试和泄漏检测1.0版
它可以回答的问题和可以解决的问题包括:
·我使用了多少内存?
·我的代码中哪些部分分配的内存最多?
·是否存在内存泄漏--我在哪里没有释放内存
发表于 08-28 08:05
评论