近期开发了一个小型Web应用，使用了uWSGI和web.py，遇到了一个内存泄露问题折腾了好久，记录一下，希望可以帮助别人少踩坑。
P.S. 公司项目，我不能把完整代码贴上来，所以大部分是文字说明，以下配置文件中的路径也是虚构的。
环境说明
Ubuntu 13.10
uWSGI 1.9.13
web.py 0.37
sqlite3 3.7.17 2013-05-20
nginx 1.4.7
nginx配置作为Web前端，通过domain socket和uWSGI服务器交互：
server {
listen xxxx;
access_log off;
location / {
uwsgi_pass unix:///tmp/app/uwsgi.sock;
include uwsgi_params;
}
}
uWSGI配置：
[uwsgi]
app_path = /spec/app
log_dir = /log/app
tmp_dir = /tmp/app
master = true
processes = 4
threads = 2
pidfile = %(tmp_dir)/uwsgi.pid
socket = %(tmp_dir)/uwsgi.sock
chdir = %(app_path)
plugin = python
module = index
daemonize = %(log_dir)/uwsgi.log
log-maxsize = 1000000
log-truncate = true
disable-logging = true
reload-on-as = 30
reload-on-rss = 30
问题现象
该应用使用了uWSGI提供的定时器功能来执行定时任务，发现运行一段时间后就会有内存泄露。仔细观察发现，即使没有外部请求，也会有内存泄露；有时候外部请求会使得泄露的内存被回收。
问题分析
泄露发生在定时器函数中？
在应用中使用uWSGI的定时器功能的代码如下：
import uwsgi
# add timers
timer_list = [
# signal, callback, timeout, who
(98, modulea.timer_func, modulea.get_interval, ""),
(99, users.timer_func, 60, ""),
]
for timer in timer_list:
uwsgi.register_signal(timer[0], timer[3], timer[1])
if callable(timer[2]):
interval = timer[2]()
else:
interval = timer[2]
uwsgi.add_timer(timer[0], interval)
因为之前使用过同样的环境开发了另一个应用，没用使用uWSGI的定时器，所以怀疑内存泄露是定时器导致的。
首先，删掉定时器后，发现uWSGI进程不会发生内存泄露了。确定是定时器中的代码导致的内存泄露。
然后把定时器中的代码放到一个请求处理函数中去执行，通过构造HTTP请求来触发代码执行。结果是没有内存泄露。因此，结论是同一段代码在定时器中执行有内存泄露，在请求处理代码中执行没有内存泄露。
这个实验也把导致内存泄露的代码锁定到了
users.timer_func函数中，其他函数都没有内存泄露问题。
啥东西泄露了？
users.timer_func函数只作了一件事情，就是从sqlite3数据库中读取用户表，修改所有用户的某些状态值。先来看下代码：
def update_users():
user_list = Users.objects.all()
if user_list is None:
return
for eachuser in user_list:
# update eachuser's attributes
...
# do database update
eachuser.update()
def timer_func(signal_num):
update_users()
Users类是一个用户管理的类，父类是Model类。其中的Users.objects.all()是通过Model类的一个新的元类实现的，主要代码如下：
def all(self):
db = _connect_to_db()
results = db.select(self._table_name)
return [self.cls(x) for x in results]
也就是利用web.py的数据库API连接到数据库，然后读取一张表的所有行，把每一行的都实例化成一个Users实例。
综上所述，导致内存泄露的users.timer_func函数主要的操作就是创建数据库连接，然后读写数据表。这个时候，我们可以猜测内存泄露可能是数据库连接没关导致的，因为我们自己创建的Users实例在函数退出后应该都被回收了。
如何验证这个猜测呢？因为sqlite数据库是文件型数据库，进程中每个连接相当于打开一个文件描述符，所以可以使用lsof命令查看uWSGI到底打开了多少次数据库文件：
# 假设2771是其中一个uWSGI进程的PID
$lsof -p 2771 | grep service.db | wc -l
通过不断执行这个命令，我们发现如下规律：
如果是在定时器中执行数据库操作，每次执行都打开数据库文件一次，但是没有关闭（上述命令输出的值在增加）
如果是请求处理函数中执行数据库操作，则数据库文件被打开后会被关闭（上述命令输出的值不变）
到这边我们可以确认，泄露的是数据库连接对象，而且只有在定时器函数中才会泄露，在请求处理函数中不会。
为啥数据库连接会泄露？
这个问题困扰了我很久。最后采用最笨的办法去解决 -- 阅读web.py的源码。通过阅读源码可以发现，web.py的数据库操作主要代码是在class DB中，真正的数据库连接则存放在DB类的_ctx成员中。
class DB:
"""Database"""
def __init__(self, db_module, keywords):
"""Creates a database.
"""
# some DB implementaions take optional paramater `driver` to use a specific driver modue
# but it should not be passed to connect
keywords.pop('driver', None)
self.db_module = db_module
self.keywords = keywords
self._ctx = threadeddict()
...
def _getctx(self):
if not self._ctx.get('db'):
self._load_context(self._ctx)
return self._ctx
ctx = property(_getctx)
...
其他具体操作代码就不贴了，这里的关键信息是self._ctx = threadeddict()。这说明了数据库连接是thread local对象，即线程独立变量，在线程被销毁时会自动回收，否则就一直保存着，除非手动销毁。可以查看Python的threading.local的文档。于是，我开始怀疑，是不是uWSGI的定时器线程一直没有销毁，而处理请求的线程则是每次处理请求后都销毁，导致了数据库连接的泄露呢？
为了证实这个猜想，继续作实验。这次用上了gc模块（也可以用objgraph模块，不过这个问题中gc已经够用了）。将下面代码分别加入到定时器函数中和请求处理函数中：
objlist = gc.get_objects()
print len([x for x in objlist if isinstance(x, web.ThreadedDict)])
然后我们可以在uWSGI的log中看到ThreadedDict的统计值。结果果然如我们所猜想的：不断执行定时器函数会让这个统计值不断增加，而请求处理函数中则不会。
所以，我们也就找到了数据库连接泄露的原因，也就是内存泄露的原因：uWSGI中定时器函数所对应的线程不会主动销毁thread local数据，导致thread local数据没有被回收。
由于每个uWSGI进程可能只开启一个线程，也可能有多个线程，因此可以总结的情况大概有如下几种：
只有一个线程时：如果该线程一直在运行定时器函数，则在此期间该进程不会重新初始化，thread local对象不会被回收。当该线程处理请求时，会重新初始化线程，thread local对象会被回收，释放的内存会被回收。
当有多个线程时：每个线程自身的情况和上面描述的一致，不过有可能出现一个线程一直在运行定时器函数的情况（也就是内存一直泄露）。
解决方案
在定时器函数退出前，清除web.py存放在thread local中的对象。代码如下：
def timer_func(signal_num):
update_users()
# bypass uWSGI timer function bug: timer thread doesn't release
# thread local resource.
web.ThreadedDict.clear_all()
P.S.
该方法目前还没发现副作用，如果有的话那就是把别人存放的数据也给清除了。
其他版本的uWSGI服务器没测试过。
为啥处理请求的线程不会有内存泄露呢？
处理请求的线程为什么就可以主动销毁thread local的数据呢？难道uWSGI对不同的线程有区别对待？其实不是的，如果一个线程在处理HTTP请求时，会调用WSGI规范定义的接口，web.py在实现这个接口的时候，先执行了ThreadedDict.clear_all()，所以所有thread local数据都被回收了。定时器线程是直接调用我们的函数，如果我们不主动回收这些数据，那么就泄露了。我们可以看下web.py的WSGI接口实现（在web/application.py文件中）：
class application:
...
def _cleanup(self):
# Threads can be recycled by WSGI servers.
# Clearing up all thread-local state to avoid interefereing with subsequent requests.
utils.ThreadedDict.clear_all()
def wsgifunc(self, *middleware):
"""Returns a WSGI-compatible function for this application."""
...
def wsgi(env, start_resp):
# clear threadlocal to avoid inteference of previous requests
self._cleanup()
self.load(env)
try:
# allow uppercase methods only
if web.ctx.method.upper() != web.ctx.method:
raise web.nomethod()
result = self.handle_with_processors()
if is_generator(result):
result = peep(result)
else:
result = [result]
except web.HTTPError, e:
result = [e.data]
result = web.safestr(iter(result))
status, headers = web.ctx.status, web.ctx.headers
start_resp(status, headers)
def cleanup():
self._cleanup()
yield '' # force this function to be a generator
return itertools.chain(result, cleanup())
for m in middleware:
wsgi = m(wsgi)
return wsgi
默认的入口函数是class application的wsgifunc()函数的内部函数wsgi()，它第一行就调用了self._cleanup()。