利用进程信息追查内存泄漏

一、问题现象

Bigpipe是Baidu公司内部的分布式传输系统，其服务器模块Broker采用异步编程框架来实现，并大量使用了引用计数来管理对象资源的生命周期和释放时机。在对Broker模块进行压力测试过程中，发现Broker长时间运行后，内存占用逐步变大，出现了内存泄漏问题。

二、初步分析

针对近期Broker的升级改造点，确定Broker中可能出现内存泄漏的对象。Broker新增了监控功能，其中一项是对服务器各个参数的监控统计，这必然对参数对象有读取操作，每次操作都将引用计数“加一”，并在完成操作后“减一”。当前，参数对象有数个，需要确定是哪个参数对象泄漏了。

三、代码&业务分析

1.     为证明之前的初步分析的结果，可能的方法有是：使用Valgrind运行Broker并启动压力程序复现可能的内存泄漏。但是，使用这种方法：

1)    由于内存泄漏的触发条件并不简单，可能导致复现周期很长，甚至无法复现同样的内存泄漏；

2)    内存泄漏的对象放置在容器中，valgrind正常退出后不报告相关的内存泄漏；

经过另外的测试集群短时间的运行尝试进行复现，果然Valgrind报告未出现异常。

2.     分析现有拥有的条件：幸好，出现“内存泄漏”问题的Broker进程仍然在运行中，真相就在这个进程内部。应该充分利用已有的现场，完成问题的定位。初步希望使用GDB调试。

3.     挑战：使用GDB attach pid的方法将会导致进程挂起，按Broker的设计，一当配对另一个主/从Broker不互相发送心跳， Broker也将自动退出程序，退出后现场就无法保存，这意味着使用GDB的机会只有一次。

4.     方案：利用gdb打印内存信息并从信息中观察可能的内存泄漏点。

5.     步骤一：pmap -x {PID}查看内存信息（如：pmap -x 24671）；得到类似如下信息，注意标记为anon的位置：

6.     步骤二：启动gdb ./bin/broker并使用 attach {PID}命令加载现有进程；例如上述进程号为24671，则使用：