2个压箱底的方法和工具搞定内存泄漏

这篇具有很好参考价值的文章主要介绍了2个压箱底的方法和工具搞定内存泄漏。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

导读|遭受内存泄露往往是令开发者头疼的问题,传统分析工具 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 分配实际物理页面,并将虚拟内存与其相关联,记录至页表。

其中,步骤一至三均为虚拟内存,步骤四分配实际物理内存并创建相应页表。

2个压箱底的方法和工具搞定内存泄漏

 相关视频推荐

内存泄漏的3个解决方案与原理实现,知道一个可以轻松应对开发

【C++开发】5种内存泄漏检测方式,让你重新理解C++内存管理

免费学习地址:c/c++ linux服务器开发/后台架构师

需要C/C++ Linux服务器架构师学习资料加qun812855908获取(资料包括C/C++,Linux,golang技术,Nginx,ZeroMQ,MySQL,Redis,fastdfs,MongoDB,ZK,流媒体,CDN,P2P,K8S,Docker,TCP/IP,协程,DPDK,ffmpeg等),免费分享

2个压箱底的方法和工具搞定内存泄漏

 

传统分析工具 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。

2个压箱底的方法和工具搞定内存泄漏

 如上图所示,现有 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 及其变体的关键代码路径。

2个压箱底的方法和工具搞定内存泄漏

 

  • 未释放内存分配火焰图

执行以下命令,追踪 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 内存泄露发生的地方。而另一处并非真正的泄露。该工具有一定的副作用,由于追踪的最后阶段有一些刚分配的内存还未来得及释放,需要进一步阅读源码甄别。另外,建议多运行几次对比下结果,排除那些经常变化的分配路径。

2个压箱底的方法和工具搞定内存泄漏

 对已分配但未释放的代码路径展开,结果如下:

2个压箱底的方法和工具搞定内存泄漏

 

2个压箱底的方法和工具搞定内存泄漏

 相比全量内存分配火焰图,数据量减少近 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 。

2个压箱底的方法和工具搞定内存泄漏

 

  • 开发新工具 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。(注:非内存泄露发生的环境,仅用来演示缺页异常火焰图)

2个压箱底的方法和工具搞定内存泄漏

 相比现有版,该版本的数据量减少 20 多倍,需要重点关注的代码路径减少也比较明显。

总结

本文以 TDSQL 实际生产中 mysql-proxy 内存泄露问题作为分析对象,探索基于动态追踪技术的通用内存泄露(增长)分析方法:内存分配器行为分析缺页异常事件分析,并针对现有分析工具进行改进,形成相应的分析工具 memstacks、pgfaultstacks,欢迎各位开发者尝试去开发。工具使用者仅需关注少数可能导致内存泄露的代码路径,有效提升定位内存泄露(增长)问题的效率。如果你正在遭受内存泄露(增加)的困扰,不妨尝试下本文提及的分析方法和工具,希望有所帮助。文章来源地址https://www.toymoban.com/news/detail-407306.html

到了这里,关于2个压箱底的方法和工具搞定内存泄漏的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Android 内存泄漏、性能分析常用工具

    一、内存泄漏 1、 MAT-eclipse :“Memory Analyzer Tool”,一个基于Eclipse的内存分析工具,是一个快速、功能丰富的JAVA heap分析工具,它可以帮助我们查找内存泄漏和减少内存消耗。 2、Leakcanary :一款开源的自动检测内存泄漏的工具。 3、AndroidStudio Profiler :Android Studio 3.0 采用全新

    2024年02月12日
    浏览(52)
  • 简单使用AndroidStudio 官方Profiler工具进行内存泄漏检查

    Android studio(下面简称AS)为App提供的性能分析工具,在AS3.0+替换掉旧的分析工具,对于其使用方法,官方也有对应的介绍:Android Profiler 对于使用方法,我只用到比较简单的功能,高级的还没用到,使用案例进行简答的使用,在此之前,你可能需要到官方文档中了解Profiler中

    2023年04月08日
    浏览(47)
  • Android内存泄漏分析及检测工具LeakCanary简介,Android进阶

    @Synchronized override fun expectWeaklyReachable( watchedObject: Any, description: String ) { if (!isEnabled()) { return } removeWeaklyReachableObjects() val key = UUID.randomUUID() .toString() val watchUptimeMillis = clock.uptimeMillis() val reference = KeyedWeakReference(watchedObject, key, description, watchUptimeMillis, queue) SharkLog.d { \\\"Watching \\\" +

    2024年04月25日
    浏览(41)
  • Python中的内存泄漏及其检测方法

    一、引言 内存泄漏是编程中常见的问题之一,它会导致程序在运行过程中不断消耗内存,最终可能导致程序崩溃或性能下降。在Python中,内存泄漏也是一个需要关注的问题。本文将详细介绍Python中的内存泄漏及其检测方法,以帮助读者更好地理解和解决这个问题。 二、Pyth

    2024年02月22日
    浏览(59)
  • K8s 内存泄漏处理方法

    问题描述: 产生的所有文件如下: runc Kubelet 替换前的文件 检查kmem是否关闭前需要将此节点的pod杀掉重启或者重启服务器,当结果为0时成功 [root@k8s-master ~]# cat /sys/fs/cgroup/memory/kubepods/burstable/memory.kmem.usage_in_bytes [root@k8s-master ~]# cat /sys/fs/cgroup/memory/kubepods/memory.kmem.slabinfo 12. 经

    2024年02月13日
    浏览(48)
  • android 如何进行内存泄漏检测及解决方法

    内存泄漏是在Android开发中常见的问题之一,它可能导致应用的内存占用逐渐增加,最终影响应用的性能和稳定性。以下是一些常见的方法来进行内存泄漏检测和解决: 1. 使用工具进行内存泄漏检测: Android Profiler: Android Studio提供的Android Profiler工具可以帮助您监视应用的内

    2024年02月07日
    浏览(51)
  • C/C++内存泄漏原因分析与应对方法

    一、内存泄漏的危害: 内存泄漏会导致当前应用程序消耗更多的内存,使得其他应用程序可用的内存更少了。 如果有个进程可用的内存不够,就会触发Linux操作系统的直接/后台内存回收(即将一些内存页的数据写到磁盘里,那么该页也就可用了,脏页回写)。虽然后台回收

    2024年02月16日
    浏览(50)
  • Android之内存泄漏与内存溢出

    内存泄漏(memory leak):是指程序在申请内存后,无法释放已申请的内存空间,导致系统无法及时回收内存并且分配给其他进程使用。通常少次数的内存无法及时回收并不会到程序造成什么影响,但是如果在内存本身就比较少获取多次导致内存无法正常回收时,就会导致内存

    2024年02月13日
    浏览(50)
  • 记一次项目内存优化--内存泄漏

    主要是与某个版本作基准进行对比(一般是最新版本的前一个版本作原数据),优化后,PSS有所下降,线上OOM率减少(Bugly版本对比),泄漏点减少(从捉取一些线上上传回来的内存堆栈信息分析,或本地测试后dump下hprof文件分析)。 了解什么是内存泄漏 了解虚拟机中的对象

    2024年02月12日
    浏览(77)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包