Nginx 中 Master Process 怎么进行进程资源统计-Nginx-PHP中文网

nginx 的 master process 不进行资源统计，所有 cpu、内存、连接数和请求量等指标均由 worker 进程独立产生；获取整体资源使用需直接监控 worker 或借助 stub_status、共享内存模块（如 vts）、访问日志外部分析等手段。

nginx 中 master process 怎么进行进程资源统计

Nginx 的 Master Process 不进行进程资源统计。它本身不采集、不聚合、也不维护任何关于 CPU、内存、连接数或请求量的运行时指标。

它的职责是管理——读配置、拉起 Worker、响应信号、平滑重启、监控子进程存活性。所有实际的资源消耗和业务指标，都由 Worker 进程各自独立产生并持有。

所以，“Master 进行资源统计”这个说法在 Nginx 原生架构中并不成立。你需要的是如何获取 Nginx 整体资源使用情况，而这个过程必然绕过 Master，直接面向 Worker 或借助外部手段。

这是最常用、最直接的方式，因为资源消耗主体就是 Worker：

查看各 Worker 的物理内存（RSS）和 CPU 占用：

ps -o pid,user,%cpu,%mem,rss,vsz,comm -C nginx | grep worker

注意：ps aux 中 RSS（常驻内存）比 VSZ（虚拟内存）更能反映真实内存压力；单个 Worker 通常占用几十 MB，若持续超 200MB，需排查是否缓存过大、body 缓冲设置过高或存在内存泄漏。

这类数据每个 Worker 独立维护，没有全局变量。常见做法有三种：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

stub_status 暴露 + 脚本聚合
启用 ngx_http_stub_status_module，为每个 Worker 绑定本地端口（如 127.0.0.1:8080、:8081 等），再用脚本并发请求并累加：
```
Active connections: 123
server accepts handled requests
 123456 123456 234567
Reading: 5 Writing: 12 Waiting: 106
```
总请求数 = 所有 Worker 的 requests 字段之和。
共享内存模块（如 vts）
使用 nginx-module-vts 等第三方模块，将统计写入 shared memory zone，多个 Worker 可读写同一区域，实现近实时聚合，输出 JSON 接口供监控系统调用。
访问日志 + 外部分析
将 access_log 输出到文件或转发至 Kafka/Fluentd，再由 Prometheus + nginxlog-exporter 或 Logstash 解析，按时间窗口汇总 QPS、状态码分布、响应时间 P95 等。

避免误判的关键是验证实际运行身份和父子关系：

区分 Master 和 Worker：
```
ps -eo pid,ppid,user,comm,args | grep nginx
```
- Master 的 PPID 通常是 1（systemd）或 shell PID，USER 是 root，ARGS 含 master process
- Worker 的 PPID 是 Master 的 PID，USER 是配置的非特权用户（如 www-data）
检查 Worker 是否真以降权用户运行：
```
ls -l /proc/$(pgrep -f "nginx: worker" | head -1)/status 2>/dev/null | grep -E 'Uid|Gid'
```
输出应显示 Uid: 33 33 33 33（对应 www-data UID），而非 0 0 0 0。
验证日志与临时目录权限是否匹配该用户，否则 Worker 会因权限失败退出或静默丢请求。