Python Web服务内存持续上涨大概率是对象被意外长期持有,如全局缓存未清理、__del__导致循环引用卡住、C扩展缺陷等;需用psutil和gc.get_stats()区分真泄漏与缓存预占,结合objgraph和memray定位根因。

容器里 Python Web 服务内存持续上涨,大概率不是 GC 失效,而是对象被意外长期持有——比如全局缓存没清、回调没解绑、循环引用配了 __del__,或者用了带内存缺陷的 C 扩展库。K8s 的 OOM Killer 杀进程只是表象,根源在代码逻辑层。
确认是不是真泄漏:别把缓存增长当泄漏
先排除“假阳性”:内存 RSS 上涨 ≠ 泄漏。很多框架(如 Django 的模板缓存、FastAPI 的 lru_cache)或中间件(如 SQLAlchemy 连接池)会主动预占内存。关键看趋势是否单调不可逆。
- 用
psutil.Process().memory_info().rss每 30 秒打点,持续跑 2 小时以上,观察曲线是否有平台期或回落 - 对比相同请求压测下,容器启动后 5 分钟 vs 60 分钟的
gc.get_stats()输出,重点关注collected字段是否归零或骤降 - 如果只在特定请求路径(如上传大文件、导出报表)后内存不回落,优先盯住该路径的临时对象生命周期
查全局变量和模块级缓存:最常见泄漏源
Web 服务里最易被忽略的是模块顶层字典、列表或类属性。它们随模块加载而常驻,引用计数永不归零。
- 搜索所有
_cache、_pool、_registry、GLOBAL_前缀的变量,检查是否有清理逻辑(如定时clear()或 LRU 驱逐) - 用
objgraph.show_growth(limit=20)在请求前后各执行一次,重点关注数量激增的类型(如dict、list、str),再用objgraph.find_backref追到持有者 - 替换方案:把
dict改成weakref.WeakValueDictionary;用functools.lru_cache(maxsize=128)替代手写缓存;连接池必须设max_overflow和pool_timeout
盯死循环引用 + __del__:GC 会绕过它
只要对象定义了 __del__ 方法,哪怕只是打印日志,Python 就会把它放进“不可收集集合”。这类对象在 gc.garbage 里永久滞留,且不会触发 __del__ —— 它们只是卡住了。
调用 Cutout.Pro 视觉处理 API 进行背景移除、人像抠图和照片增强,支持文件上传与图片 URL 输入。
立即学习“Python免费学习笔记(深入)”;
- 启动时加
gc.set_debug(gc.DEBUG_UNCOLLECTABLE),看日志是否频繁输出uncollectable对象 - 搜索项目中所有
def __del__(self):,尤其注意 ORM 模型、异步任务类、自定义上下文管理器 - 替代方案:用
weakref.finalize(obj, callback)替代__del__;用contextlib.closing或__exit__管理资源;双向引用处强制用weakref.ref存 parent
容器环境特有陷阱:C 扩展、日志、健康检查
容器里内存泄漏常和宿主环境耦合:比如某些 C 扩展(pycurl、旧版 numpy)在 musl libc(Alpine 镜像)下不释放内存;日志 handler 被重复注册;健康检查接口本身触发泄漏。
- 镜像优先用
python:3.11-slim-bullseye(glibc)而非alpine,除非你明确验证过所有 C 依赖在 musl 下行为正常 - 检查
logging.getLogger()是否在每次请求里重复addHandler(),导致 handler 链无限增长 - 把健康检查端点(如
/health)单独剥离,用最小依赖的脚本实现,避免引入业务代码的引用链 - 在 Dockerfile 里加
ENV PYTHONMALLOC=malloc,禁用 Python 内存池,让valgrind或memray能准确定位 C 层泄漏
真正难排查的泄漏,往往藏在第三方库的 C 扩展里——比如某个版本的 pillow 在处理 GIF 动画帧时未释放解码缓冲区。这时候得靠 memray 录制火焰图,直接看到哪一行 C 函数分配了内存却没 free。别迷信“库很成熟”,容器里运行时间越长,越容易暴露底层内存管理缺陷。

















