worker_processes设为cpu逻辑核心数（或auto）最能减少资源争抢，因其使每个单线程事件驱动的worker进程绑定一个cpu核心，避免上下文切换、跨核缓存失效和accept锁竞争；auto模式自动适配各类环境并规避人为误配。
worker_processes 设为 CPU 逻辑核心数（或直接用 auto）最能减少资源争抢。
为什么是 CPU 核心数？
Nginx 每个 worker 进程是单线程、事件驱动的，天然适合绑定一个 CPU 核心运行。这样可避免：
- 多个进程挤在同一个核上，引发频繁上下文切换
- 跨核调度导致 L1/L2 缓存失效，增加延迟
- 共享监听端口时的 accept 锁竞争（即使有 accept_mutex，仍存在唤醒开销）
auto 是生产环境首选
写成 worker_processes auto; 即可，Nginx 启动时自动读取当前可用逻辑核心数。它的好处包括：
- 适配物理机、虚拟机、容器等不同环境
- 在 Kubernetes 中配合
--cpuset-cpus限制时，仍能正确感知分配核数 - 避免人为误判——比如宿主机 32 核但容器只分到 2 核，手动写 32 反而有害
需要手动调低的几种情况
不是所有场景都必须“满配”，以下情形建议减少 worker 数量：
- 大量长连接（如 WebSocket、gRPC），每个 worker 内存和文件描述符压力大，可设为物理核心数的 1/2～3/4
- 磁盘 I/O 密集（如未启用 sendfile 的大文件下载），过多 worker 会加剧磁盘队列争用
- 与数据库、Java 应用共部署，需预留 CPU 给其他服务
配套设置不能少
只调 worker_processes 不够，必须同步检查：
-
worker_cpu_affinity auto;：让每个 worker 固定绑定一个核心，提升缓存局部性 -
worker_rlimit_nofile和系统级ulimit -n：确保文件描述符足够支撑worker_processes × worker_connections - 启用
reuseport（Linux 3.9+）：内核层面分流新连接，彻底规避惊群问题
