排查Tornado内存泄漏：加密货币组合应用内存异常增长

嘿，我来帮你梳理下怎么排查这个内存泄漏问题——毕竟你提到之前Tornado运行稳定，只是更新了其他模块后才出问题，那突破口大概率就在那些更新的模块以及它们和WebSocket连接的交互上。下面是一步步的排查方向：

1. 先确认内存泄漏的真实情况 #

• 首先得明确是持续的内存增长不释放，还是有波动但总体上升。可以用PyPy自带的内存分析工具启动应用：pypy --memory-profile your_app.py，它会生成内存使用的快照，你可以对比不同时间点的快照，看哪些对象在不断累积。
• 也可以用objgraph库（PyPy下兼容），定期调用objgraph.show_growth(limit=10)，观察哪些对象类型的数量在持续增加——这能帮你快速定位到泄漏的对象类别。

2. 重点排查你更新的那些模块 #

既然你没碰WebSocket相关代码，那更新的模块就是头号嫌疑：

• 检查这些模块是否新增了全局缓存、单例对象，或者在被SockJSConnection实例引用后，没有在连接关闭时释放。比如如果你的连接实例里存了某个更新模块的对象，但连接关闭时没把这个引用置为None，PyPy的GC可能无法回收这些对象。
• 看看更新的模块有没有引入持久化的回调或定时器：比如调用了IOLoop.current().add_periodic_callback或者add_callback，但没有在连接关闭时取消这些任务——这些任务会被Tornado的IOLoop持有，进而导致连接实例和相关对象无法被GC。
• 排查是否使用了非PyPy友好的C扩展：有些Python模块的C扩展在PyPy下可能存在内存管理问题，更新版本后可能触发了这类隐藏bug，导致对象引用计数异常。

3. 间接检查SockJSConnection的生命周期 #

虽然你没改这部分代码，但更新的模块可能间接影响了连接的清理逻辑：

• 确认SockJSConnection的on_close方法是否被正确调用：如果更新的模块里有未捕获的异常，可能导致连接关闭时的清理代码没执行。可以在on_close里加日志，验证每次连接断开时这个方法都会触发。
• 检查连接实例上的外部引用：比如你在连接里存储了更新模块的对象，关闭时有没有主动解除这些引用？比如self.module_obj = None，避免循环引用或者全局引用导致GC无法回收。
• 查看Tornado IOLoop中的handler：更新的模块是否在连接建立时注册了额外的IOLoop handler，但关闭时没移除？这些handler会一直持有连接实例，导致内存无法释放。

4. 用排除法定位问题模块 #

• 尝试逐个回滚更新的模块，恢复到之前的版本，每次恢复后运行应用观察内存变化。如果回滚某个模块后内存泄漏消失，那这个模块就是问题根源，再深入排查它的版本变化点。
• 临时禁用WebSocket的实时更新功能，看内存是否还增长——如果不增长了，说明泄漏和连接与更新模块的交互有关；如果还是增长，那问题可能出在更新模块本身的全局对象上。

5. 其他小概率排查点 #

• 检查日志模块：如果更新的模块开启了过于详细的日志，且日志对象没有被正确回收，也可能导致内存累积（不过这个概率较低）。
• 确认PyPy与Tornado的兼容性：你用的PyPy 5.9.0和Tornado 4.4.2虽然之前没问题，但更新模块后可能触发了之前没暴露的兼容性bug，可以尝试临时切换到CPython环境运行，看是否还会泄漏，以此区分是PyPy特有的问题还是通用问题。

内容的提问来源于stack exchange，提问作者Jack Mullen