内存泄漏通常发生在python后端而非nginx；需先用ps/ipcs/pmap排查nginx worker内存是否持续增长及共享内存残留，再通过tracemalloc、objgraph定位python中全局容器、未清理回调等泄漏源，并优化nginx缓冲、超时与日志配置。

排查 Nginx + Python 部署中因内存泄漏导致的长期性能下降，关键在于区分责任边界：Nginx 本身不执行 Python 代码，它通常通过反向代理（如 proxy_pass）或 FastCGI 将请求交给独立的 Python 应用服务器（如 Gunicorn、uWSGI、Uvicorn）。因此，“内存泄漏”大概率发生在 Python 后端进程，而非 Nginx worker 进程本身——但 Nginx 的配置不当会放大泄漏影响，甚至掩盖真实问题。

确认泄漏位置：先分清是 Nginx 还是 Python

别一上来就查 Python。先快速排除 Nginx 层异常：

• 运行 ps -o pid,rss,comm -C nginx，只看 worker 进程（忽略 master），观察 RSS 是否随时间持续上升（比如每小时涨 10MB+ 且不回落）；若稳定在几十 MB 内波动，基本可排除 Nginx 自身泄漏
• 检查 ipcs -m | grep nginx，确认没有残留的共享内存段（如 proxy_cache 或第三方模块创建的 SHM）长期累积
• 用 pmap -x $(pgrep -f 'nginx: worker') 查看内存映射，重点看 anon-rss 和 mapped 区域是否异常膨胀；若大部分内存来自 libpython 或 .so 模块，说明 Python 进程可能被错误地嵌入或绑定

聚焦 Python 后端：定位泄漏源头

绝大多数情况下，内存增长来自 Python 应用进程。需在其运行环境中直接分析：

A Python CLI skill for Cutout.Pro visual APIs — background removal, face cutout, and photo enhancement. Supports file upload & image URL input.

调用 Cutout.Pro 视觉处理 API 进行背景移除、人像抠图和照片增强，支持文件上传与图片 URL 输入。

下载

• 启用 tracemalloc（Python 3.4+ 内置）：在应用启动时加入初始化代码，定期 dump top 分配栈，例如每 5 分钟输出一次前 20 名分配点，能精准定位哪行代码反复 new 对象
• 用 objgraph 抓取对象增长趋势：在服务运行数小时后执行 objgraph.show_most_common_types(limit=20)，重点关注 dict、list、str、自定义类实例是否线性增长；再用 objgraph.find_backref_chain 追踪某个可疑对象的持有链
• 检查全局容器：搜索代码中所有 module-level list/dict、类变量缓存（如 User.cache = {}）、未设 TTL 的 LRU 缓存、日志缓冲区——这些是泄漏高发区，尤其在长连接或异步任务场景下
• 审查回调与事件注册：若用 asyncio、Celery 或 WebSockets，确认每个 add_done_callback、on_message 都有对应清理逻辑；忘记 unregister 或 disconnect 会导致 handler 实例永久驻留

检查 Nginx 与 Python 的交互配置

Nginx 本身不泄漏，但错误配置会让 Python 泄漏更难察觉或加速恶化：

• 禁用不必要的缓冲：关闭 proxy_buffering off（若后端已处理流式响应），避免 Nginx 在内存中囤积大响应体；调小 proxy_buffers 4 8k 而非默认的 8×16k
• 限制单请求资源占用：设置 client_max_body_size 2m、client_header_timeout 10s，防止单个恶意请求拖垮整个 Python 进程内存
• 避免长连接滥用：Python 应用若未正确复用数据库连接或 HTTP 会话，Nginx 的 keepalive 32 可能让泄漏进程长时间得不到重启机会；适当缩短 proxy_http_version 1.1 下的 idle 超时
• 验证日志级别：生产环境禁用 error_log ... debug，调试日志本身会显著增加内存分配压力，干扰泄漏判断

建立可持续观测机制

靠人工抽查不可持续。应落地轻量级监控：

• 用 psutil 在 Python 应用内定时上报 process.memory_info().rss 到 Prometheus，配合 Grafana 看内存曲线是否“阶梯式上涨”
• 为 Gunicorn/uWSGI 配置 --max-requests 1000 --max-requests-jitter 100，强制进程轮换，缓解泄漏影响（临时手段，非根治）
• 在 CI/CD 流程中加入内存快照比对：每次部署前跑 10 分钟压测，用 tracemalloc 保存 baseline，上线后自动对比，偏差超阈值则告警

Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！