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导致的.如

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变量

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关闭就可以了

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的特性，不是真正的内存泄漏.