Nginx 中 Master Process 如何监控各进程负载

Nginx Master进程不监控Worker负载，仅管理生命周期；Worker资源需通过ps、lsof、/proc等系统工具或Prometheus等外部监控采集，并辅以配置优化降低负载风险。

Nginx 的 Master Process 本身不主动监控 Worker 进程的 CPU、内存或连接负载，它只负责进程生命周期管理（拉起、回收、信号转发）。真正的负载观测必须依赖外部系统工具和辅助机制。关键在于：Master 是管理中枢，不是监控探针。

直接查看 Worker 进程资源占用

Worker 是标准 Linux 进程，其 RSS 内存、CPU 时间、打开文件数等均可通过系统命令实时获取：

1. ps -eo pid,ppid,%cpu,%mem,rss,vsz,lstart,comm --sort=-%cpu | grep "nginx: worker"

   查看所有 worker 中 CPU 占用最高的几个

2. ps -eo pid,ppid,%cpu,%mem,rss,vsz,lstart,comm --sort=-rss | grep "nginx: worker"

   按物理内存（RSS）排序，定位内存大户

3. lsof -p <worker_pid> | wc -l

   统计某 worker 当前打开的文件描述符数量（含 socket、日志、临时文件等）

4. cat /proc/<worker_pid>/status | grep -E "VmRSS|Threads|FDSize"

   获取更底层的内存与线程信息

注意：不要只查 master 进程——它的内存/CPU 几乎恒定且极低，无参考价值。

利用信号触发状态反馈（需调试支持）

标准 Nginx 不提供内置负载上报，但启用 --with-debug 编译后可配合调试能力有限观察：

1. 向单个 worker 发送 SIGUSR2（部分 debug 分支支持）可能触发内存分配快照输出到 error_log
2. 更可靠的做法是：gdb -p <worker_pid> -ex "info proc mappings" -ex "quit" 查看运行时内存布局（仅限排查）
3. nginx -T 可确认当前生效配置，间接判断是否因配置不当（如过大 buffer）导致负载异常升高

通过外部监控体系持续采集指标

生产环境应将 Worker 负载纳入统一可观测性体系：

1. Prometheus + node_exporter：用 process_resident_memory_bytes{process_name=~"nginx.*"} 区分 master 与各 worker 的 RSS
2. 自定义采集脚本（每30秒执行）：

   pgrep -f "nginx: worker" | while read pid; dorss=$(awk '/VmRSS/ {print $2}' /proc/$pid/status 2>/dev/null)echo "nginx_worker_rss{pid="$pid"} $rss"done

3. 结合 systemd（v229+）：为 nginx service 设置 MemoryMax=512M，防止单 worker 内存失控，并通过 systemctl show nginx -p MemoryCurrent 获取实时值

配置层面降低负载波动风险

减少异常负载，比事后监控更重要：

1. 控制并发连接上限：调小 worker_connections（如从 4096 降至 2048），避免空闲连接长期驻留消耗内存
2. 限制请求体缓存：client_body_buffer_size 8k; client_max_body_size 10m; 防止大上传撑爆内存
3. 禁用非必要模块：移除 ngx_http_perl_module、ngx_http_xslt_filter_module 等重量级模块，降低初始化开销
4. 合理设置超时：proxy_read_timeout 30; keepalive_timeout 60; 避免长连接堆积拖慢响应

不复杂但容易忽略