Nginx Master进程不监控Worker负载，仅管理生命周期；Worker资源需通过ps、lsof、/proc等系统工具或Prometheus等外部监控采集，并辅以配置优化降低负载风险。
Nginx 的 Master Process 本身不主动监控 Worker 进程的 CPU、内存或连接负载，它只负责进程生命周期管理（拉起、回收、信号转发）。真正的负载观测必须依赖外部系统工具和辅助机制。关键在于：Master 是管理中枢，不是监控探针。
直接查看 Worker 进程资源占用
Worker 是标准 Linux 进程，其 RSS 内存、CPU 时间、打开文件数等均可通过系统命令实时获取：
-
ps -eo pid,ppid,%cpu,%mem,rss,vsz,lstart,comm --sort=-%cpu | grep "nginx: worker"
查看所有 worker 中 CPU 占用最高的几个 -
ps -eo pid,ppid,%cpu,%mem,rss,vsz,lstart,comm --sort=-rss | grep "nginx: worker"
按物理内存（RSS）排序，定位内存大户 -
lsof -p <worker_pid> | wc -l
统计某 worker 当前打开的文件描述符数量（含 socket、日志、临时文件等） -
cat /proc/<worker_pid>/status | grep -E "VmRSS|Threads|FDSize"
获取更底层的内存与线程信息
注意：不要只查 master 进程——它的内存/CPU 几乎恒定且极低，无参考价值。
利用信号触发状态反馈（需调试支持）
标准 Nginx 不提供内置负载上报，但启用 --with-debug 编译后可配合调试能力有限观察：
- 向单个 worker 发送
SIGUSR2（部分 debug 分支支持）可能触发内存分配快照输出到 error_log - 更可靠的做法是：
gdb -p <worker_pid> -ex "info proc mappings" -ex "quit"查看运行时内存布局（仅限排查） -
nginx -T可确认当前生效配置，间接判断是否因配置不当（如过大 buffer）导致负载异常升高
通过外部监控体系持续采集指标
生产环境应将 Worker 负载纳入统一可观测性体系：
-
Prometheus + node_exporter：用
process_resident_memory_bytes{process_name=~"nginx.*"}区分 master 与各 worker 的 RSS -
自定义采集脚本（每30秒执行）：
pgrep -f "nginx: worker" | while read pid; do rss=$(awk '/VmRSS/ {print $2}' /proc/$pid/status 2>/dev/null) echo "nginx_worker_rss{pid=\"$pid\"} $rss" done -
结合 systemd（v229+）：为 nginx service 设置
MemoryMax=512M，防止单 worker 内存失控，并通过systemctl show nginx -p MemoryCurrent获取实时值
配置层面降低负载波动风险
减少异常负载，比事后监控更重要：
- 控制并发连接上限：调小
worker_connections（如从 4096 降至 2048），避免空闲连接长期驻留消耗内存 - 限制请求体缓存：
client_body_buffer_size 8k; client_max_body_size 10m;防止大上传撑爆内存 - 禁用非必要模块：移除
ngx_http_perl_module、ngx_http_xslt_filter_module等重量级模块，降低初始化开销 - 合理设置超时：
proxy_read_timeout 30; keepalive_timeout 60;避免长连接堆积拖慢响应
不复杂但容易忽略
