这几天一直在忙着赶项目,一个基于django的日志分析系统,之前已经有基本的雏形,这一次主要是给它做代码的整理及重构部分模块.为了保持代码的一致性,除了Web部分用了django,后台程序与数据库的交互也采用了django的框架. 我在后台python脚本模块中,直接import了django的models
1
2
3
4
5
6
|
import
sys
from
django.core.management
import
setup_environ
sys.path.append(
'/test/web_site/'
)
import
settings
setup_environ(settings)
from
mysql.models
import
*
|
通过这样,后台其他程序就可以直接通过django与数据库打交道,处理日志的守护进程也是这么做的,但随着运行时间的加长,我发现进程所占用的内存越来越大. 内存泄漏~! 我的程序逻辑并不复杂,唯一有内存泄漏的可能也就是不断重复执行的一个循环,几行代码,但我看了好久也没发现有问题的地方. 而且python的内存管理机制相当自动化,极少有出现内存无法释放的问题,常见的range(n)和交叉引用导致的内存不回收的情况,代码中并没有采用. 这让我十分疑惑
只能硬着头皮调试,几行代码,我就没用啥高级的调试方法,直接一行行的注释掉来观察,最后发现是django的数据库API导致的.如
1
2
3
|
from
mysql.models
import
test_log as logtable
p
=
logtable(times
=
valuedic[
'times'
],ipadd
=
valuedic[
'ipadd'
])
p.save()
|
在p.save(),把数据插入数据库后,这一部分的内存就不会释放了,加上del p 或者p = None都无济于事. 搜来搜去也没发现其他人有遇到类似的问题,幸福的是最后我还是在一篇e文中找到了点线索
原文地址:http://blog.webfaction.com/tips-to-keep-your-django-mod-python-memory-usage-down
文中第一条就提到:Make sure that you set DEBUG to False in settings.py,在DEBUG模式下,所有的SQL查询都会被保存在内存中.
我顿时想起,由于我整个项目还在调试阶段,这个DEBUG变量是设置为True的
DEBUG设置为False后,内存泄漏的问题就不复存在了
可我整个项目还需要调试,不能就这么简单的关闭DEBUG模式,怎么办? 我一开始想在后台模块import settings后再重新设置DEBUG变量
1
2
3
4
5
6
7
|
import
sys
from
django.core.management
import
setup_environ
sys.path.append(
'/test/web_site/'
)
import
settings
settings.DEBUG
=
False
setup_environ(settings)
from
mysql.models
import
*
|
可经过测试,这样做并无法生效,怎么回事? 原来setup_environ时把整个模块都传过去了,这样的方法行不通.
最后我用了折衷的方法, copy一份settings,等项目完工后,再把原settings的DEBUG关闭就可以了
1
2
3
4
5
6
|
import
sys
from
django.core.management
import
setup_environ
sys.path.append(
'/test/web_site/'
)
import
settings_for_db as settings
setup_environ(settings)
from
mysql.models
import
*
|
之所以标题用引号,因为这只是一个DEBUG模式下django的特性,不是真正的内存泄漏.