应设为cpu物理核心数，如4核则worker_processes 4；需配合worker_cpu_affinity auto、worker_rlimit_nofile 65535及events块中use epoll和worker_connections等参数协同优化，并在容器中按cgroup限制调整，避免静默降级。
直接设为 CPU 物理核心数，是最稳妥、最有效的起点。不是越多越好，也不是盲目用 auto 就万事大吉——关键在匹配负载类型和硬件实际可用资源。
先确认真实 CPU 资源
别依赖直觉或宿主机信息，尤其在容器或虚拟化环境：
- 查物理拓扑：
lscpu | grep -E "(CPU\(s\)|Core|Socket)"，重点关注 CPU(s)（逻辑核）、Core(s) per socket（每路物理核数） - 容器内运行时，看 cgroup 限制：
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us和/sys/fs/cgroup/cpu/cpu.cfs_period_us，算出分配的 vCPU 数 - 超线程（HT）开启的 8 核 16 线程 CPU，通常仍设为
worker_processes 8;；仅在高并发静态文件且实测有效时，才尝试 10～12
按负载类型动态调整
一个值打天下不现实，要根据你跑的是什么业务来微调：
-
通用 Web 服务（HTTP/HTTPS + 静态资源）：设为物理核心数，例如 4 核 →
worker_processes 4; - 大量反向代理 + 长连接（如 WebSocket、gRPC）：每个 worker 内存与 fd 压力大，建议设为物理核心数的 1/2～3/4，如 8 核可设为 4 或 6
- SSL/TLS 终止频繁（软件加解密）：CPU 计算吃紧，可比物理核心数多配 1～2 个，如 8 核 → 9 或 10
-
混合部署（Nginx 与 DB/Java 共存）：预留 1～2 核给其他服务，设为
$(nproc --all)-2并写入启动脚本
必须同步配置的关键配套参数
只改 worker_processes 不够，否则效果打折甚至报错：
-
worker_cpu_affinity auto;：让每个 worker 绑定独立核心，避免迁移开销（Linux 3.2+ 支持） -
worker_rlimit_nofile 65535;：在 main 块中提升单进程文件描述符上限，匹配worker_connections -
events { use epoll; multi_accept on; worker_connections 4096; }：显式指定高效事件模型，一次接收多个连接 - 系统级 ulimit 必须跟上：
nginx用户的nofile软硬限制需 ≥worker_rlimit_nofile
验证是否生效
改完不验证等于没改：
- 重载后执行：
ps -eo pid,psr,comm | grep nginx，检查各 worker 是否分布在不同 CPU 编号上 - 观察
top或htop：所有 worker 的 %CPU 应大致均衡，总和接近 N×100%（N 为 worker 数） - 启用
stub_status模块，访问/nginx_status，关注 Active connections 和 Waiting 比例；Waiting 长期偏高，说明连接队列积压，应优先调大worker_connections而非增加 worker 数 - 务必执行
nginx -t语法检查，再nginx -s reload生效，不要 kill 进程重启
