如何在Python中排查Django进程内存泄漏与高CPU占用问题-Python教程-PHP中文网

先确认是否真泄漏：Django进程内存持续上涨、CPU长期高于70%且无请求峰值，才是排查起点；用psutil每5秒采样RSS和cpu_percent(interval=1)，监控各worker，关注QuerySet缓存、循环引用及py-spy抓帧定位。

如何在python中排查django进程内存泄漏与高cpu占用问题

不靠猜，先确认是不是真泄漏——Django 进程的内存持续上涨、CPU 长期高于 70% 且无明显请求峰值，才是排查起点。直接在生产环境跑 top 或 htop 容易漏掉瞬时毛刺，建议用 psutil 写个轻量脚本挂后台采样：

示例（每 5 秒记录一次）：

os.getpid()

关键点：

必须用 p.cpu_percent(interval=1)，传 interval 才能获取真实增量；不传或传 0 会返回自进程启动以来的平均值，完全失真
rss 是实际物理内存占用，比 vms 更反映真实压力；注意单位换算，避免误判为“几百 GB”这种假警报
如果用 Gunicorn/Uvicorn，要对每个 worker 单独监控，主进程 CPU 低不代表没泄漏

Django 的 QuerySet 是惰性求值，但一旦被多次遍历、转成 list、或参与 len()/bool() 判断，就会缓存结果集。缓存不会自动释放，尤其在长生命周期的 Celery task 或管理命令中极易堆积。

典型症状：内存曲线随请求次数阶梯式上升，重启后归零，且 gc.get_objects() 中大量出现 QuerySet 实例。

实操建议：

禁用不需要的缓存：在 QuerySet 后链式调用 .iterator(chunk_size=2000)，强制流式读取，不缓存
显式清空：对已缓存的 QuerySet，调用 qs._result_cache = None（虽是私有属性，但稳定可用）
避免在循环里重复构造相同 QuerySet：把 Model.objects.filter(...) 提到循环外，或用 values_list('id', flat=True) 减少对象实例化开销

Python 的 GC 能处理大多数引用环，但遇到带 __del__ 方法的对象（如某些数据库连接池、异步库封装类），或 C 扩展中未正确管理引用计数时，gc.collect() 会失败，残留对象进入 gc.garbage ——这是内存泄漏的铁证。

快速验证方法：

Python 编程规范

Python 编程规范与最佳实践。强制 PEP 8 代码风格、语法校验、单元测试执行，适用于代码编写、审查和重构。触发词：Python、代码规范、py_compile、单元测试。

下载

import gc
gc.set_debug(gc.DEBUG_SAVEALL)  # 开启调试模式
gc.collect()
print(len(gc.garbage))  # >0 表示存在无法回收的环

常见诱因：

定位技巧：打印 gc.garbage[0].__class__ 和 gc.get_referrers(gc.garbage[0])，顺藤摸瓜找谁在强引用它。

cProfile 需要重启服务且影响性能，py-spy 是真正的无侵入方案，尤其适合线上紧急诊断。

安装与基本用法：

PID

重点关注：

火焰图中长时间占据顶部的函数，尤其是 json.dumps、django.template.base.Template.render、或某次数据库查询的 execute 调用 —— 往往对应 N+1 查询或模板过度渲染
py-spy dump -p PID 输出所有线程栈，检查是否有线程卡在 select.select（I/O 阻塞）、或反复执行同一段序列化逻辑
如果发现大量 __new__ 调用集中在某个模型类，大概率是该模型被高频实例化且未及时释放（比如日志中间件里无节制创建 Model 实例）

真正棘手的是那些不常触发、但每次触发就吃掉几百 MB 的场景——比如某次导出接口加载了全部用户数据再做内存排序。这类问题不会在常规监控里暴露，只能靠 py-spy 在问题发生瞬间抓帧。