nginx -s reload 会引发内存短暂翻倍，因新旧配置结构体并存；随后旧worker退出、主进程释放旧结构，内存回落，但glibc可能延迟归还操作系统。
nginx -s reload 确实是“热重载”，但不是零开销操作。它在保持服务不中断的前提下，会触发一系列内存和进程状态变化，其中内存的短暂波动是正常现象，关键在于理解波动来源和是否可控。
reload 的核心流程决定内存行为
执行 reload 时，Nginx 主进程（master）并非直接替换自身配置，而是分阶段推进：
- 先完整解析新配置，构建一套全新的内存结构（含监听套接字、缓存区、模块上下文等）；
- 此时旧配置结构仍在内存中——新旧两套结构体并存，内存占用自然临时翻倍；
- 随后 fork 出新 worker 进程，让它们加载新结构体并开始接受新连接；
- 旧 worker 进程收到 QUIT 信号后，不再 accept 新连接，只处理完已有请求，再释放自身持有的旧结构体；
- 主进程最终释放旧配置结构体，内存回落至正常水平。
哪些配置变更会放大内存波动
并非所有 reload 都引起明显内存上涨。以下几类配置变动会让内存“涨得更久、更高”：
- 启用或扩大 proxy_cache / fastcgi_cache：缓存区初始化需分配大量内存，新旧 worker 可能同时持有缓存元数据；
- 增大 client_max_body_size 或 large_client_header_buffers：每个连接预留缓冲区变大，worker 进程启动时即预分配更多内存；
- 加载大型第三方模块（如 subs_filter 处理大响应体）：模块内部可能申请大块堆内存，且未及时释放（如未调用 malloc_trim）；
- 配置了大量 server 块或 location 嵌套层级过深：配置树结构复杂，解析和存储开销显著上升。
为什么 reload 后内存没立刻回落
看起来“reload 完内存还是高”，往往不是 bug，而是 glibc 的内存管理机制所致：
- Nginx 使用 malloc/free 管理堆内存，free 后内存通常仍由 glibc 持有，并不立即归还操作系统；
- 只有当高地址空闲内存块足够大、且满足条件时，glibc 才可能通过 sbrk 或 mmap 调整 brk 值，把内存交还内核；
- 若系统长期高负载、内存碎片多，这块“已 free 但未归还”的内存可能持续数分钟甚至更久；
- 可手动触发优化：在 reload 后调用 pstack 查看 worker 进程，确认无异常驻留；必要时可在 Nginx 编译时加 --with-debug 并启用 malloc_trim 调优。
如何判断波动是否属于风险信号
短期波动（1–2 分钟内回落）属预期行为；若出现以下情况，需深入排查：
- 多次 reload 后内存持续阶梯式上升，且不回落 → 怀疑模块级内存泄漏（如 ngx_http_substitutions_filter_module 处理大 JSON 时）；
- worker 进程 RSS 持续高于其他节点 2 倍以上，且 reload 无法修复 → 检查是否误启调试模块、日志级别过高、或共享内存段残留（ipcs -m）；
- 伴随 error.log 中频繁出现 malloc(N) failed → 不是波动，是真实内存不足，需检查上游响应体大小或限制 body_filter 缓冲区。
