首先,settings.py 中的 DEBUG = False
,所以不,connections['default'].queries
不会不断增长,直到用完所有内存。
让我们从我从 django.contrib.auth.models.User
加载的 User
表开始,其中包含 10000 个用户(每个名为 'test# ' 其中 # 是 1 到 10000 之间的数字)。
这里是 View :
from django.contrib.auth.models import User
from django.http import HttpResponse
import time
def leak(request):
print "loading users"
users = []
users += list(User.objects.all())
users += list(User.objects.all())
users += list(User.objects.all())
users += list(User.objects.all())
users += list(User.objects.all())
users += list(User.objects.all())
users += list(User.objects.all())
users += list(User.objects.all())
users += list(User.objects.all())
users += list(User.objects.all())
users += list(User.objects.all())
users += list(User.objects.all())
users += list(User.objects.all())
users += list(User.objects.all())
users += list(User.objects.all())
users += list(User.objects.all())
users += list(User.objects.all())
print "sleeping"
time.sleep(10)
return HttpResponse('')
我已将上面的 View 附加到 /leak/
url 并启动开发服务器(使用 DEBUG=False,我已经测试过,它没有 nothing与运行开发服务器和其他实例有关)。
运行后:
% curl http://localhost:8000/leak/
runserver 进程的内存增长到从下面的 ps aux
输出中看到的大小,然后保持在该级别。
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
dlamotte 25694 11.5 34.8 861384 705668 pts/3 Sl+ 19:11 2:52 /home/dlamotte/tmp/django-mem-leak/env/bin/python ./manage.py runserver
然后运行上面的 curl
命令似乎并没有增加实例的内存使用量(我预计这是真正的内存泄漏?),它必须重新使用内存?但是,我觉得这里有问题,内存没有释放到系统(但是,我理解python不释放内存可能会更好的性能)。
在此之后,我天真地试图看看 python 是否会释放它分配的大块内存。所以我从 python session 中尝试以下操作:
>>> a = ''
>>> a += 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' * 10000000
>>> del a
内存按预期分配在 a += ...
行,但是当 del a
发生时,内存被释放。为什么 django 查询集的行为不同?这是 django 打算做的事情吗?有没有办法改变这种行为?
我确实花了 2 天时间来调试这种行为,但不知道下一步该去哪里(我已经学会了使用 guppy 和 objgraph,这似乎没有指向我能弄清楚的任何有趣的东西)。
更新:这可能只是工作中的 python 内存管理,与 Django 无关(在 django-users 邮件列表中建议),但我想通过在 python 中以某种方式复制它来确认在 Django 之外。
更新:使用 python 版本 2.6.5
最佳答案
我决定将我的评论移到答案中以使事情更清楚。
从 Python 2.5 开始,CPython 内存分配会跟踪小对象分配器的内部内存使用情况,并尝试将完全空闲的区域返回给底层操作系统。这在大多数情况下都有效,但对象无法在内存中移动这一事实意味着碎片可能是一个严重的问题。
试试下面的实验(我用的是3.2,但是如果你用xrange的话2.5+应该差不多):
# Create the big lists in advance to avoid skewing the memory counts
seq1 = [None] * 10**6 # Big list of references to None
seq2 = seq1[::10]
# Create and reference a lot of smaller lists
seq1[:] = [[] for x in range(10**6)] # References all the new lists
seq2[:] = seq1[::10] # Grab a second reference to 10% of the new lists
# Memory fragmentation in action
seq1[:] = [None] * 10**6 # 90% of the lists are no longer referenced here
seq2[:] = seq1[::10] # But memory freed only after last 10% are dropped
注意,即使您删除了对 seq1
和 seq2
的引用,上述序列也可能会让您的 Python 进程占用大量额外内存。
当人们谈论 PyPy 使用比 CPython 更少的内存时,这是他们谈论的主要部分。因为 PyPy 在底层不使用直接指针引用,所以它能够使用压缩 GC,从而避免了大部分碎片问题,并且更可靠地将内存返回给操作系统。
关于python - 为什么在 django 中进行大型查询(或一系列查询)后内存没有释放到系统?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/5494178/