关键不是设多少进程，而是看运行是否健康：通过stub_status观察waiting、reading+writing、accepts/handled差异，结合ps/top验证cpu绑定与负载均衡，并关联连接增长与响应延迟，动态调优后reload并观察效果。
直接看 Nginx 自身的状态数据，比凭经验猜配置更可靠。关键不是“设多少”，而是“当前运行是否健康”——状态指标会告诉你 worker 进程是不是忙得不均、卡在哪儿、或根本没吃饱。
用 stub_status 看实时连接分布
先确保已启用 stub_status 模块（在 server 或 location 块中添加）：
stub_status;
allow 127.0.0.1;
deny all;
}
访问该地址后，你会看到类似：
Active connections: 1245server accepts handled requests
2345678 2345678 12345678
Reading: 12 Writing: 89 Waiting: 1144
重点关注三项：
- Waiting 长期高于 Active 的 80%，说明大部分连接处于空闲等待状态，worker 没有瓶颈，当前进程数可能已足够，甚至偏多
-
Reading + Writing 持续接近或等于
worker_connections设置值，而Active又很高，说明单个 worker 处理压力大，可考虑适当增加worker_processes（但要同步检查系统资源） - 若
accepts ≠ handled（差值持续增大），可能有 worker 进程异常退出或响应阻塞，需结合日志查原因，不是单纯加进程能解决的
结合 ps 和 top 验证 CPU 绑定与负载均衡
运行：ps -eo pid,psr,comm | grep nginx | grep worker
查看每个 worker 进程实际运行在哪个 CPU 核上（psr 列）。
再打开 htop 或 top，按 1 显示各核使用率。理想状态是：
- 每个 worker 对应一个核心，且该核心 %CPU 在 60–90% 波动（非长期 99% 或长期 10%）
- 没有某个 worker 长期独占一核跑满，其他核却空闲——这说明负载不均，可能是
accept_mutex未生效，或存在阻塞操作（如未开启 sendfile 的大文件读取） - 所有 worker 的 CPU 使用率总和接近
N × 100%（N 为 worker 数），说明资源被有效利用
观察连接增长与响应延迟的相关性
在压测或真实流量上升时，同时采集两组数据：
- 每秒新连接数（可通过
nginx_status中accepts差值计算） - 平均响应时间（如通过 access_log 中
$request_time统计，或用 Prometheus + nginx-vts-exporter）
如果连接数线性上升，但响应时间陡增、错误率升高，而 CPU 总体使用率未超 70%，大概率不是 CPU 不够，而是：
- 单个 worker 承载连接数已达上限（检查
worker_connections是否过小） - 存在 I/O 阻塞（如磁盘慢、SSL 握手耗时高），此时加 worker 效果有限，应优先启用
aio on、sendfile on、硬件加速 SSL - 系统级限制触发（如
ulimit -n不足，导致accept()失败，日志中可见 “too many open files”）
动态调优：改完别忘 reload 和验证
修改 worker_processes 后：
- 务必先执行
nginx -t校验语法 - 用
nginx -s reload平滑加载，不中断连接 - 等 2–3 分钟，再对比前后
stub_status和htop数据，确认变化是否符合预期 - 避免连续高频 reload，每次调整后至少观察一个业务高峰周期
不复杂但容易忽略的是：状态数据不会自动说话，它只反映结果。你需要把“Waiting 高”“某核 99%”“accepts/handled 差值拉大”这些信号，对应到具体配置项或系统行为上，才能真正调准。
