python 内存泄露的诊断 - 独立思考 - ITeye技术网站

python 内存泄露的诊断 - 独立思考 - ITeye技术网站

python 内存泄露的诊断

博客分类：

• 编程语言: Python

Python多线程Blog.net 

对于一个用 python 实现的，长期运行的后台服务进程来说，如果内存持续增长，那么很可能是有了“内存泄露”。
最近在我的项目中，就出现了内存持续增长的情况，goolge 了一下，发现 Tracing Python memory leaks 讲了一种诊断方式，并给出了实例。而我的案例与此文稍有不同，下面就结合我的案例，谈谈如何诊断内存泄露：

一、内存泄露的原因
对于 python 这种支持垃圾回收的语言来说，怎么还会有内存泄露？ 概括来说，有以下三种原因：

1、 所用到的用 C 语言开发的底层模块中出现了内存泄露。
2、 代码中用到了全局的 list、 dict 或其它容器，不停的往这些容器中插入对象，而忘记了在使用完之后进行删除回收
3、 代码中有“引用循环”， python 垃圾处理机制无法进行回收

二、 内存泄露的诊断思路

无论是哪种方式的内存泄露，最终表现的形式都是某些 python 对象在不停的增长；因此，首先是要找到这些异常的对象。

三、 内存泄露的诊断步骤

用到的工具： gc 模块和 objgraph 模块
objgraph 是一个用于诊断内存问题的有用的工具

1、 在服务程序的循环逻辑中，选择出一个诊断点

2、 在诊断点，插入如下诊断语句

1. import gc  
2. import objgraph  
3. ### 强制进行垃圾回收  
4. gc.collect()  
5. ### 打印出对象数目最多的 50 个类型信息  
6. objgraph.show_most_common_types(limit=50)  

import gc
import objgraph
### 强制进行垃圾回收
gc.collect()
### 打印出对象数目最多的 50 个类型信息
objgraph.show_most_common_types(limit=50)

3、 检查统计信息，找到异常对象。

运行加入诊断语句的服务程序，并将打印到屏幕上的统计信息重定向到日志中。
运行一段时间后，就可以来分析日志，看看哪些对象在不停的增长。

以我的程序为例，我将日志记录到 log.txt 中，运行一段时间后，发现 tuple 和 list 类型的对象不停增长：

1. # grep "^list " log.txt  
2. # grep "^tuple " log.txt  

# grep "^list " log.txt
# grep "^tuple " log.txt

如果不停增长的对象，是一些非通用的类型（例如你自己实现的一个 class），那么问题就比较好定位，例如 Tracing Python memory leaks中提到的案例。

而对 tuple 和 list 这类通用类型，要想知道对象到底是什么，泄露发生在哪里，还得想点办法。我采用了排查的方式。由于程序的模块化还不错，可以每次禁用一个模块，然后重新跑程序，重新检查日志，看看 tuple 和 list 是否仍然不停增长。这样，很快就能将故障定位到具体的模块中。

最后终于找到了原因，属于上面总结的第二种原因：
我的程序是一个多线程程序，多个线程作为生产者，一个线程作为消费者，通过将一个 tuple 对象送入异步队列进行通信。由于消费者的处理速度跟不上生产者的速度，又没有进行同步， 导致异步队列中的对象越来越多。

四、参考文档
1. http://www.lshift.net/blog/2008/11/14/tracing-python-memory-leaks
2. http://mg.pov.lt/blog/python-object-graphs.html
3. http://mg.pov.lt/blog/hunting-python-memleaks