Nginx无内置Master监控Worker内存机制，需通过ps/pgrep等系统工具采集各Worker的RSS值实现观测；可脚本化采集并告警，结合配置优化（如调小缓冲区、禁用冗余模块）降低内存压力。
Nginx 本身不提供 Master 进程主动监控 Worker 进程内存占用的内置机制，但可通过外部手段结合 Nginx 进程模型实现有效观测与干预。
理解 Master/Worker 进程内存行为
Master 进程仅负责管理（启动、平滑重启、信号转发、日志重开等），几乎不处理请求，内存占用极低且稳定；真正消耗内存的是 Worker 进程——每个 Worker 独立处理连接，其内存随并发连接数、缓冲区配置、模块使用（如 proxy_buffer、gzip、Lua）显著增长。因此，“监控 Worker 内存”本质是监控 各 worker 进程的 RSS/VSS 内存指标，而非由 Master 主动采集。
通过系统工具实时查看 Worker 内存
利用 Linux 进程信息接口，可快速获取每个 Worker 的内存使用情况：
-
按进程名筛选并排序：
ps -C nginx -o pid,ppid,rss,vsz,comm --sort=-rss输出中rss（Resident Set Size）即常驻物理内存，是最关键指标；ppid可确认是否为 Master（父进程 PID 通常为 1 或 systemd）或 Worker（父进程 PID 是 Master 的 PID）。 -
结合 pgrep 定位 Worker PID 并批量查内存：
for pid in $(pgrep -P $(pgrep nginx)); do echo "PID $pid: $(ps -o rss= -p $pid) KB"; done | sort -k2 -nr -
持续观察变化：用
watch命令每 2 秒刷新一次watch -n 2 'ps -C nginx -o pid,rss,vsz,comm --sort=-rss | head -10'
自动化监控与告警建议
单纯手动查看无法满足生产环境需求，推荐以下轻量方案：
-
用脚本定期采集并写入日志或指标端点：例如每分钟执行一次
ps命令，提取所有 Worker 的rss，计算平均值、最大值，写入 Prometheus 的文本文件采集器（textfile collector）或直接推送到 Telegraf。 -
设置 RSS 阈值触发动作：当任一 Worker 的 RSS 超过预设值（如 500MB），可自动执行
nginx -s reload（注意 reload 会新建 Worker，旧 Worker 逐步退出，内存自然释放），或发送告警（邮件/钉钉/Webhook）。 - 避免误判泄漏的细节提示：Worker 内存短期上涨可能是正常负载升高所致；需关注 长期缓慢增长 + 不随请求下降而回落 的趋势，才更可能指向内存泄漏（如某些第三方模块未正确释放资源）。
配合 Nginx 配置降低内存风险
从源头减少 Worker 内存压力，比事后监控更治本：
- 合理设置
worker_connections和events.use（推荐epoll），避免单个 Worker 承载过多连接。 - 调小缓存相关参数：
client_body_buffer_size、proxy_buffer_size、fastcgi_buffer_size等，尤其在代理大文件或高并发场景下影响显著。 - 禁用非必要模块（如未用 Lua 就不加载
ngx_http_lua_module），部分动态模块可能存在内存管理缺陷。 - 启用
reset_timedout_connection on，及时清理僵死连接，防止缓冲区持续占用。
