一、问题现象：你的Nginx服务器在"偷偷长胖"吗？

想象一下，你的Nginx服务器就像一个正在做俯卧撑的健身教练。正常情况下它应该保持稳定的体型（内存占用），但某天你发现它的"体重"（RSS内存）不断上涨，甚至出现了"虚胖"（内存碎片）。这时候就要警惕内存泄漏了！

典型症状包括：

  • worker_processes占用内存持续增长不释放
  • 系统free -m显示可用内存阶梯式下降
  • 监控图表出现"锯齿状"内存曲线
  • 最终导致OOM Killer强制终止进程

生产环境真实案例： 某电商网站在大促期间发现Nginx内存每小时增长200MB，通过以下命令观察到异常：

top -o %MEM

# 查看指定进程的详细内存映射
pmap -x <nginx_worker_pid> | tail -n1
# 输出示例：
# total kB          3956480  294712  288320
# 其中RSS（294MB）持续上涨

二、排查工具箱

1. 基础体检
# 内存趋势监控（每5秒采样）
watch -n5 "free -m; echo; ps -eo pid,rss,comm | grep nginx"

# 内存泄漏特征检测
valgrind --leak-check=full --show-leak-kinds=all \
         --track-origins=yes --log-file=valgrind.log \
         /usr/sbin/nginx -t
2. GDB内存快照对比
# 第一次内存快照
gdb -p <worker_pid> -ex "info proc mappings" -ex detach > mem1.log

# 间隔30分钟后再次采样
gdb -p <worker_pid> -ex "info proc mappings" -ex detach > mem2.log

# 对比内存区域变化
diff -y --suppress-common-lines mem1.log mem2.log
3. jemalloc内存分析
# 重新编译Nginx时加入调试参数
./configure --with-debug \
            --with-ld-opt="-ljemalloc" \
            --add-module=/path/nginx-module-vts

通过jeprof工具生成火焰图：

jeprof --show_bytes --pdf /usr/sbin/nginx jeprof.*.heap > report.pdf

三、一个动态模块泄漏的完整排查

场景描述：

某视频网站的自研鉴权模块导致worker内存每小时泄漏300MB

排查过程：
  1. 使用strace追踪内存分配：
strace -f -e trace=mmap,munmap,brk -o strace.log /usr/sbin/nginx

分析日志发现munmap调用频率异常

  1. Lua模块内存池检测：
-- 在access_by_lua_block中添加检测代码
local mem_used = collectgarbage("count")
ngx.log(ngx.NOTICE, "Lua memory: ", mem_used, " KB")
  1. 核心转储分析：
gcore <worker_pid>
strings core.12345 | grep -A20 "leaked_string"
最终定位：

第三方模块在ngx_http_finalize_request阶段未正确释放ngx_palloc分配的内存

四、内存管理的明暗面

1. Nginx内存池设计
  • 优势：层级式内存池减少系统调用
  • 缺陷：大块内存无法及时释放
// 典型错误示例（伪代码）
ngx_pool_t *pool = ngx_create_pool(4096, log);
char *buf = ngx_palloc(pool, 1024);
// 忘记调用ngx_destroy_pool(pool);
2. 第三方模块开发规范
  • 必须实现ngx_module_ctx中的exit_thread函数
  • 使用NGX_HAVE_DEBUG_MALLOC编译选项检测

五、根治方案

  1. 热修复方案：
# 限制worker进程内存
worker_rlimit_core 500M;
worker_rlimit_nofile 65535;
  1. 长期方案：
# 使用tcmalloc替代方案
./configure --with-google_perftools_module \
            --with-ld-opt="-ltcmalloc"
  1. 监控增强：
# 在Prometheus中添加内存碎片率指标
nginx_worker_memory_fragmentation_ratio{instance="$host"} > 1.5

六、应用场景与技术选型

场景类型 推荐工具 响应时间 精度
生产环境 gdb+pmap组合 <1分钟 中等
测试环境 Valgrind全程检测 30分钟 高
模块开发阶段 AddressSanitizer 实时 极高
云原生环境 eBPF+pprof 5秒 中等

七、避坑指南：五个"不要"

  1. 不要在生产环境直接使用kill -ABRT
  2. 不要随意调整worker_connections与内存的比值
  3. 不要在未验证的情况下使用第三方内存分配器
  4. 不要忽视max_requests参数的自动回收机制
  5. 不要忘记检查glibc版本对malloc_trim的影响

八、总结升华

通过本文的排查方法论，我们不仅学会了如何应对Nginx内存泄漏，更重要的是建立了服务端内存管理的系统性思维。记住：内存问题就像牙疼，早期发现成本最低，等到OOM发作时就只能"拔牙"了！