worker_processes 应设为物理核心数，容器中需查cgroup限额，超线程仍按物理核设置；结合业务类型微调：通用服务设为物理核数，长连接减至1/2～3/4，SSL密集型可加1～2个，混合部署需预留CPU；必须同步配置worker_cpu_affinity、worker_rlimit_nofile、epoll及系统ulimit，并通过ps、htop和stub_status验证效果。
worker_processes 直接决定 Nginx 能并行处理请求的“通道数”，它和 worker_connections 共同构成并发能力的底层乘积关系：最大理论并发 ≈ worker_processes × worker_connections。但这个数字不是越大越好，关键在于匹配 CPU 实际可用资源、负载类型和系统限制。
按物理核心数设是最稳起点
默认 auto 可能误判（尤其在容器或虚拟机中），手动设为 CPU 物理核心数更可靠：
- 查真实物理核数：
lscpu | grep -E "CPU\(s\)|Core|Socket"，重点关注 “Core(s) per socket” 和 “Socket(s)” 的乘积 - 容器内要查 cgroup 限额：
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us /sys/fs/cgroup/cpu/cpu.cfs_period_us，若比值为 4，则最多用 4 个 vCPU - 超线程（HT）开启时，仍按物理核数设；例如 8 核 16 线程，优先设
worker_processes 8
根据业务类型微调更有效
一个固定值无法覆盖所有场景，需结合实际工作负载动态调整：
- 通用 Web 服务（静态资源 + 普通 API）：设为物理核心数，如 4 核 →
worker_processes 4 - 大量长连接（WebSocket/gRPC/反向代理）：每个 worker 内存与文件描述符压力大，建议设为物理核数的 1/2～3/4，如 8 核可设 4 或 6
- 高频率 SSL 终止（软件加解密）：CPU 计算密集，可多配 1～2 个，如 8 核 → 9 或 10
- 混合部署（Nginx 与数据库共存）：预留 1～2 核给其他服务，用
worker_processes $(nproc --all - 2)并写入启动脚本
必须配套的关键参数
只改 worker_processes 几乎没效果，以下参数必须同步设置：
-
worker_cpu_affinity auto;：让每个 worker 绑定独立 CPU 核，避免调度抖动（Linux 3.2+ 支持） -
worker_rlimit_nofile 65535;：提升单进程文件描述符上限，需与系统 ulimit 一致 - events 块中：
use epoll; multi_accept on; worker_connections 4096;—— 显式启用高效事件模型，并允许一次接收多个连接 - 系统级 ulimit 必须跟上：
nginx用户的 soft/hard nofile 均 ≥ 65535
验证是否真正生效
改完配置不验证，等于没调：
- 重载后执行：
ps -eo pid,psr,comm | grep nginx，确认各 worker 分布在不同 CPU 编号上 - 用
htop观察：所有 worker 的 CPU 使用率应大致均衡，总和接近 N×100% - 启用
stub_status，访问/nginx_status，关注 Active 连接数与 Waiting 比例；Waiting 长期偏高，说明连接队列积压，应优先调大worker_connections，而非盲目增 worker 数
