排查nginx内存泄漏与异常退出需分层验证：先通过dmesg和error.log确认oom killer杀进程，再监控worker rss持续增长，注释第三方模块定位泄漏源，最后用valgrind结合调试编译聚焦ngx_palloc_large调用栈。
排查 Nginx 内存泄漏与进程异常退出，核心是“分层验证 + 工具直击”：先确认现象是否真实存在，再快速隔离问题来源，最后用调试工具锁定代码级缺陷。不靠猜，靠可观测信号和可复现路径。
看系统日志，确认是否真被 OOM Killer 杀掉
内存泄漏的终点常是进程被系统强制终止。这不是 Nginx 主动崩溃，而是内核干预的结果：
- 执行 dmesg | grep -i "killed process" | grep nginx，查找类似 Out of memory: Killed process 12345 (nginx) 的记录
- 同步检查 Nginx error.log，搜索 "exited on signal 9" 或 "Killed"，比对时间戳是否与 dmesg 一致
- 若只看到 "worker process X exited with code 0"，大概率是正常 reload，不是 OOM
盯住 worker 进程 RSS，判断是否存在持续增长
内存泄漏的本质特征是物理内存（RSS）随时间单向爬升，且不随请求结束回落：
- 用 ps aux --sort=-%mem | head -5 或 top -p $(pgrep nginx) 持续观察 5–10 分钟
- 重点关注单个 worker 进程 RSS 是否稳定在 100MB 内，还是从 200MB 涨到 800MB 且不降
- 配合 pmap -x $(pgrep nginx | head -n1) | tail -n 10 查看内存映射分布，确认增长是否集中在堆区（[anon]）而非共享内存或代码段
注释模块、单 worker 复现，快速定位第三方模块
80% 的泄漏来自新引入或更新的第三方模块。验证方式必须简单直接：
- 打开 nginx.conf，把所有 load_module 行临时注释（如
#load_module modules/ngx_http_lua_module.so;） - 执行 nginx -t && nginx -s reload，观察 RSS 是否停止上涨
- 若恢复稳定，逐个取消注释并 reload，每次只启用一个模块，直到复现泄漏
- 为精准触发，配置 master_process off; worker_processes 1; daemon off;，并用 curl 发送能激活该模块的特定请求（如带 Lua header、含 sub_filter 路径）
用 Valgrind 抓调用栈，聚焦 ngx_palloc_large 和 pool 生命周期
定位到模块后，必须深入分配源头。Valgrind 不是泛泛而查，而是紧盯两个关键点：
- 确保 Nginx 和模块都用 -g -O0 -fno-omit-frame-pointer 编译，否则堆栈不可读
- 运行：valgrind --leak-check=full --show-leak-kinds=all --log-file=valgrind.log /path/to/nginx -c conf/nginx.conf
- 只发几次目标请求，然后按 Ctrl+C 优雅退出（不能 kill -9）
- 在报告中搜索 ngx_palloc_large，检查泄漏块的调用栈是否包含你的模块函数名
- 重点审查：是否在 request pool 中分配了本该长期存活的数据？是否调用了 ngx_palloc 却没注册 ngx_pool_cleanup_t 回调？
不复杂但容易忽略：泄漏往往不出现在高频路径，而藏在异常分支、错误处理或缓存初始化逻辑里。盯住“只在特定条件触发”的那段代码。
