我在Django上运行了一个小的多线程脚本,随着时间的推移,它开始使用越来越多的内存。让它运行一整天后,RAM使用量会达到约6GB,就会开始交换。
根据http://www.lshift.net/blog/2008/11/14/tracing-python-memory-leaks提供的信息,在仅使用800M的内存时,以下是最常见的类型:
(Pdb) objgraph.show_most_common_types(limit=20)
dict 43065
tuple 28274
function 7335
list 6157
NavigableString 3479
instance 2454
cell 1256
weakref 974
wrapper_descriptor 836
builtin_function_or_method 766
type 742
getset_descriptor 562
module 423
method_descriptor 373
classobj 256
instancemethod 255
member_descriptor 218
property 185
Comment 183
__proxy__ 155
程序没有显示任何奇怪的问题。现在我该怎么做来帮助调试内存问题?
更新:尝试一些人们推荐的方法。我让程序过夜运行,当我醒来时,已使用了50%*8G==4G的RAM。
(Pdb) from pympler import muppy
(Pdb) muppy.print_summary()
types | # objects | total size
========================================== | =========== | ============
unicode | 210997 | 97.64 MB
list | 1547 | 88.29 MB
dict | 41630 | 13.21 MB
set | 50 | 8.02 MB
str | 109360 | 7.11 MB
tuple | 27898 | 2.29 MB
code | 6907 | 1.16 MB
type | 760 | 653.12 KB
weakref | 1014 | 87.14 KB
int | 3552 | 83.25 KB
function (__wrapper__) | 702 | 82.27 KB
wrapper_descriptor | 998 | 77.97 KB
cell | 1357 | 74.21 KB
<class 'pympler.asizeof.asizeof._Claskey | 1113 | 69.56 KB
function (__init__) | 574 | 67.27 KB
这不是4G的总和,也没有给我任何需要修复的大型数据结构。unicode来自“完成”节点的set(),列表看起来只是随机的weakref
。
我没有使用guppy,因为它需要C扩展,而且我没有root权限,因此构建过程很痛苦。
我使用的任何对象都没有__del__
方法,并且查看库时,django和python-mysqldb似乎也没有。还有其他想法吗?