下载APP
关闭
渠道合作
推荐作者
10 分析篇 | 内存泄漏时，我们该如何一步步找到根因？
2020-09-10 邵亚方
Linux内核技术实战课
进入课程
讲述：邵亚方
时长08:45大小8.03M
你好，我是邵亚方。
通过我们前面的基础篇以及案例篇的学习，你对内存泄漏应该有了自己的一些理解。这节课我来跟你聊一聊系统性地分析内存泄漏问题的方法：也就是说，在面对内存泄漏时，我们该如何一步步去找到根因？
不过，我不会深入到具体语言的实现细节，以及具体业务的代码逻辑中，而是会从 Linux 系统上通用的一些分析方法来入手。这样，不论你使用什么开发语言，不论你在开发什么，它总能给你提供一些帮助。
如何定位出是谁在消耗内存 ？
内存泄漏的外在表现通常是系统内存不够，严重的话可能会引起 OOM (Out of Memory)，甚至系统宕机。那在发生这些现象时，惯用的分析套路是什么呢？
首先，我们需要去找出到底是谁在消耗内存，/proc/meminfo 可以帮助我们来快速定位出问题所在。
/proc/meminfo 中的项目很多，我们没必要全部都背下来，不过有些项是相对容易出问题的，也是你在遇到内存相关的问题时，需要重点去排查的。我将这些项列了一张表格，也给出了每一项有异常时的排查思路。
总之，如果进程的内存有问题，那使用 top 就可以观察出来；如果进程的内存没有问题，那你可以从 /proc/meminfo 入手来一步步地去深入分析。
接下来，我们分析一个实际的案例，来看看如何分析进程内存泄漏是什么原因导致的。
如何去分析进程的内存泄漏原因？
这是我多年以前帮助一个小伙伴分析的内存泄漏问题。这个小伙伴已经使用 top 排查出了业务进程的内存异常，但是不清楚该如何去进一步分析。
他遇到的这个异常是，业务进程的虚拟地址空间（VIRT）被消耗很大，但是物理内存（RES）使用得却很少，所以他怀疑是进程的虚拟地址空间有内存泄漏。
可以看到 app_server 这个程序的虚拟地址空间（VIRT 这一项）很大，有 285GB。
那该如何追踪 app_server 究竟是哪里存在问题呢？
如上所示，在每个整分钟的时候，VSZ 会增大 10244KB，这看起来是一个很有规律的现象。然后，我们再来看下增大的这个内存区域到底是什么，你可以通过 /proc/PID/smaps 来看（关于 /proc 提供的信息，你可以回顾我们课程的“05 讲”）：
增大的内存区域，具体如下：
可以看到，它包括：一个私有地址空间，这从 rw-p 这个属性中的 private 可以看出来；以及一个保护页 ，这从—p 这个属性可以看出来，即进程无法访问。对于有经验的开发者而言，从这个 4K 的保护页就可以猜测出应该跟线程栈有关了。
然后我们跟踪下进程申请这部分地址空间的目的是什么，通过 strace 命令来跟踪系统调用就可以了。因为 VIRT 的增加，它的系统调用函数无非是 mmap 或者 brk，那么我们只需要 strace 的结果来看下 mmap 或 brk 就可以了。
用 strace 跟踪如下：
线程数较多，如果使用 -f 来跟踪线程，跟踪的信息量也很大，逐个搜索日志里面的 mmap 或者 brk 真是眼花缭乱， 所以我们来 grep 一下这个大小 (10489856 即 10244KB)，然后过滤下就好了：
从这个日志我们可以看到，出错的是 mmap() 这个系统调用，那我们再来看下 mmap 这个内存的目的：
可以看出，这是在 clone 时申请的线程栈。到这里你可能会有一个疑问：既然线程栈消耗了这么多的内存，那理应有很多才对啊？
但是实际上，系统中并没有很多 app_server 的线程，那这是为什么呢？答案其实比较简单：线程短暂执行完毕后就退出了，可是 mmap 的线程栈却没有被释放。
我们来写一个简单的程序复现这个现象，问题的复现是很重要的，如果很复杂的问题可以用简单的程序来复现，那就是最好的结果了。
如下是一个简单的复现程序：mmap 一个 40K 的线程栈，然后线程简单执行一下就退出。
然后我们用 pidstat 观察该进程的执行，可以发现它的现象跟生产环境中的问题是一致的：
你可以看到，VSZ 每 10s 增大 40K，但是增加的那个线程只存在了 1s 就消失了。
至此我们就可以推断出 app_server 的代码哪里有问题了，然后小伙伴去修复该代码 Bug，很快就把该问题给解决了。
当然了，应用程序的内存泄漏问题其实是千奇百怪的，分析方法也不尽相同，我们讲述这个案例的目的是为了告诉你一些通用的分析技巧。我们掌握了这些通用分析技巧，很多时候就可以以不变来应万变了。
课堂总结
这节课我们讲述了系统性分析 Linux 上内存泄漏问题的分析方法，要点如下：
top 工具和 /proc/meminfo 文件是分析 Linux 上内存泄漏问题，甚至是所有内存问题的第一步，我们先找出来哪个进程或者哪一项有异常，然后再针对性地分析；
应用程序的内存泄漏千奇百怪，所以你需要掌握一些通用的分析技巧，掌握了这些技巧很多时候就可以以不变应万变。但是，这些技巧的掌握，是建立在你的基础知识足够扎实的基础上。你需要熟练掌握我们这个系列课程讲述的这些基础知识，熟才能生巧。
课后作业
请写一个内存泄漏的程序，然后观察 /proc/[pid]/maps 以及 smaps 的变化（pid 即内存泄漏的程序的 pid）。欢迎你在留言区与我讨论。
感谢你的阅读，如果你认为这节课的内容有收获，也欢迎把它分享给你的朋友，我们下一讲见。
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
09 分析篇 | 如何对内核内存泄漏做些基础的分析？
下一篇
11 基础篇 | TCP连接的建立和断开受哪些系统配置影响？