排查第三方Nginx模块内存泄漏的关键是隔离观察、精准复现与调用栈直击：先注释load_module并reload验证RSS是否停止增长，再单worker前台运行+debug日志触发特定路径，用Valgrind盯ngx_palloc_large调用栈及内存池生命周期错误，最后通过wrk压测比对VmRSS变化验证修复效果。
排查第三方模块内存泄漏，关键不是“查所有”，而是快速隔离、精准复现、工具直击分配源头。
先隔离：停用模块，确认是否是它引起的
内存持续增长但配置没变，优先怀疑刚引入或更新的模块。操作很简单：
- 打开 nginx.conf，把疑似模块的 load_module 行全部注释掉（比如
#load_module modules/ngx_http_sub_filter_module.so;） - 执行 nginx -t 确认语法无误，再 nginx -s reload
- 观察 worker 进程 RSS 内存：用 ps aux --sort=-%mem | head -5 或 top -p $(pgrep nginx)，持续盯 5–10 分钟
- 如果内存不再上涨，说明泄漏大概率来自被禁用的某个模块；再逐个启用、逐个验证，缩小范围
再复现：单 worker + 前台运行，只触发目标逻辑
模块泄漏往往只在特定请求路径下触发（比如含 sub_filter 的 location、Lua 脚本执行、或特定 header 处理）。必须让分析工具真正“看到”它：
- 配置中加三行：master_process off;、worker_processes 1;、daemon off;
- 确保 error_log 级别为 debug：error_log logs/error.log debug;
- 只发能激活该模块的请求（例如访问 /api/subs 路径，或带 X-Process-Lua: true 的头）
- 用 Ctrl+C 退出，不 kill -9——这是让 Valgrind 或 gperftools 完整捕获释放阶段的关键
后分析：看调用栈，重点盯 ngx_palloc_large 和 pool 绑定
泄漏不是随机发生的，90% 都落在两个地方：大块内存没 free，或数据挂错了内存池生命周期。分析报告时盯这些：
- Valgrind 日志里，搜索 ngx_palloc_large —— 如果大量泄漏块都从这里分配，且调用栈含你的模块名（如
ngx_http_myfilter_handler），基本锁定 - 检查模块源码中是否在
ngx_http_output_filter或 handler 链路里调用了ngx_palloc/ngx_pcalloc，但没注册ngx_pool_cleanup_t回调 - 特别注意是否把长期存活的数据（如缓存结构体）错误地分配在 request pool 上——request 结束就销毁，但数据本该活到 server 重启
最后验证：改完代码，压测对比泄漏量
修复后不能只看一次请求，要模拟真实负载：
- 用 wrk 或 ab 发 1000+ 次相同请求（确保每次都走同一模块逻辑）
- 启动前记下 cat /proc/$(pgrep nginx)/status | grep VmRSS，结束后再查，差值应趋近于 0
- 若仍缓慢上涨，说明还有 cleanup 漏洞，或存在未显式释放的 shared memory zone 引用
