Python内存泄露的诊断

最新推荐文章于 2024-07-21 17:15:31 发布

overstack

最新推荐文章于 2024-07-21 17:15:31 发布

阅读量2.9k

点赞数

分类专栏： python/java

python/java 专栏收录该内容

29 篇文章 0 订阅

订阅专栏

Python内存泄露的诊断

对于一个用 python 实现的，长期运行的后台服务进程来说，如果内存持续增长，那么很可能是有了内存方面的问题。在我曾经的一个项目中，就出现了这种内存持续增长的情况，goolge 一下，发现 Tracing Python memory leaks 讲了一种诊断方式，并给出了实例。

而我的案例与此文稍有不同，下面就结合我的案例，谈谈如何诊断这种“内存泄露”的问题。

内存泄露的原因

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

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

内存泄露的诊断思路

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

内存泄露诊断用到的工具

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

内存泄露诊断的步骤

在服务程序的循环逻辑中，选择出一个诊断点
在诊断点，插入如下诊断语句

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

检查统计信息，找到异常对象。
运行加入诊断语句的服务程序，并将打印到屏幕上的统计信息重定向到日志中。
运行一段时间后，就可以来shell脚本来分析日志，看看哪些对象在不停的增长。
- 以我的程序为例，我将日志记录到 log.txt 中，运行一段时间后，发现 tuple 和 list 类型的对象不停增长：

Shell 代码
   1 # grep "^list " log.txt
   2 # grep "^tuple " log.txt

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

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

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