apache部署python时内存持续增长等问题，主因是python应用逻辑、wsgi封装或资源生命周期管理不当；应分层排查：先查错误日志与mod_status定位进程行为，再用psutil+objgraph监控rss及对象增长，确认daemon模式、避免全局状态滥用，并通过reload-on-rss等配置临时缓解。
Apache 中部署 Python（常见于 mod_wsgi 或 CGI/WSGI 网关方式）时，若出现内存持续增长、子进程频繁退出、服务响应变慢甚至崩溃，大概率是内存泄漏叠加 Apache 进程管理机制触发的连锁反应。问题往往不在 Apache 本身，而在于 Python 应用逻辑、wsgi 封装方式或资源生命周期管理不当。排查需分层推进：先确认现象归属（是 Python 层泄漏？还是 Apache 子进程配置失当？），再聚焦定位。
看进程行为，区分泄漏源头
Apache 子进程异常退出不等于 Python 内存泄漏，但两者高度相关。先快速判断：
- 检查错误日志：
/var/log/apache2/error.log或/var/log/httpd/error_log，搜索关键词Segmentation fault、crashed、exited on signal、out of memory；若有大量child pid XXX exit signal Segmentation fault (11)，倾向 C 扩展（如 NumPy、Pillow、数据库驱动）引发的崩溃；若提示process killed by SIGKILL或系统OOM killer日志，则说明物理内存耗尽，需回溯 Python RSS 增长趋势。 - 启用
mod_status模块，访问/server-status?auto，观察SSS（sending reply）、R（reading request）、W（sending reply）状态下的子进程数量和Req（已处理请求数）。若大量进程Req值极低（如 1–5）就退出，说明请求处理中发生未捕获异常或资源初始化失败；若Req值高（如 >500）后退出，更可能是累积内存泄漏触达MaxConnectionsPerChild限制被主动回收。 - 用
ps aux --sort=-%mem | head -20查看 httpd 进程 RSS 占用，对比不同子进程差异。若个别 worker RSS 明显高于均值（例如超 300MB），且随请求增加而单调上升，基本可锁定该进程内 Python 应用存在泄漏。
监控 Python 层内存，定位泄漏对象
在 WSGI 应用入口（如 wsgi.py 或应用初始化模块）中嵌入轻量级监控，不依赖外部工具，生产环境也可长期开启：
- 用
psutil定期记录 RSS：import psutil; p = psutil.Process(); print(f"[{time.time():.0f}] RSS: {p.memory_info().rss / 1024 / 1024:.1f} MB")，每 100 次请求或每分钟打点，输出到独立日志。观察是否“只增不减”或周期性无法回落。 - 结合
gc和objgraph抓关键节点快照：在请求处理前后调用gc.collect()，再执行objgraph.show_growth(limit=10)，重点关注dict、list、function、traceback、自定义类实例数量是否持续净增长。若某类对象每次请求都 +1 且不下降，就是强线索。 - 对可疑对象做引用追踪：拿到一个持续增长的实例（如某个缓存字典），用
objgraph.show_backrefs([obj], max_depth=4, filename='backref.png')生成图谱，重点看谁持有它——常暴露为全局变量、模块级单例、未清理的回调注册表、或异步任务未 cancel 导致的Task持有帧对象。
检查 WSGI 部署模式与常见陷阱
mod_wsgi 的工作模式直接影响 Python 内存生命周期：
- 确认使用的是
daemon mode（非 embedded mode）：embedded mode 下 Python 解释器与 Apache 主进程共用，泄漏会污染所有子进程；daemon mode 可隔离、可重启，更利于诊断。检查配置中是否有WSGIDaemonProcess和WSGIProcessGroup。 - 检查
maximum-requests（对应 Apache 的MaxConnectionsPerChild）是否设得太小（如100）。过小会导致进程频繁重建，掩盖真实泄漏；过大则让泄漏积累更久才暴露。建议设为1000–5000，配合内存监控动态调整。 - 警惕全局状态滥用：WSGI 应用在 daemon process 内是多线程/多进程共享解释器的。避免在模块顶层写
CACHE = {}、CONNECTION_POOL = []；改用线程局部存储（threading.local）或带淘汰策略的缓存（functools.lru_cache(maxsize=128)），或直接交由 Redis 等外部服务管理。 - 文件/连接未关闭：Python 代码中打开的文件、数据库连接、HTTP 会话若没用
with或显式.close()，在长生命周期的 WSGI 进程中会持续累积。尤其注意aiohttp.ClientSession、sqlite3.Connection、open()等资源。
针对性验证与缓解措施
确认泄漏后，优先采用低侵入、见效快的缓解手段，再逐步修复根本原因：
- 临时加严回收策略：在 WSGI 配置中设置
reload-on-rss（mod_wsgi 4.9.0+ 支持），例如WSGIDaemonProcess myapp reload-on-rss=256，当进程 RSS 超 256MB 自动重启该 daemon 进程。 - 禁用可疑模块验证：若怀疑某第三方库（如旧版
pytz、lxml、psycopg2）导致泄漏，可在测试环境逐个注释import并压测，观察内存曲线变化。 - 升级关键组件：确保 mod_wsgi ≥ 4.9.0、Python ≥ 3.9、核心库（如
requests、sqlalchemy）为最新稳定版。很多内存泄漏已在新版中修复（例如 psycopg2-binary 2.9+ 修复了连接池句柄泄漏）。 - 添加健康检查端点：暴露一个
/health/memory接口，返回当前进程 RSS、GC 统计、关键缓存大小等，供监控系统采集，实现泄漏早期预警。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
