worker_processes 应设为实际可用CPU核心数或auto，容器环境须显式限定；需配合worker_cpu_affinity绑定核心、worker_connections与系统ulimit协同调优，I/O密集型可设1～4，CPU密集型建议贴近物理核数。
worker_processes 不是随便填个数字就行的参数，它直接决定 Nginx 能否真正用满多核 CPU。设小了压不住并发，设大了反而拖慢响应——关键在于匹配服务器实际可用的计算资源，并考虑业务负载类型。
先确认真实可用的 CPU 核心数
别只看“几核几线程”的宣传，要以系统实际分配为准：
- 物理机或裸金属：运行 nproc 查逻辑核心数（含超线程），但更推荐用 lscpu | grep -E "Core\(s\) per socket|Socket\(s\)" 计算物理核心总数；
- 容器或云主机（如 Kubernetes、AWS EC2）：nproc 输出才是真实 vCPU 数，/proc/cpuinfo 可能暴露宿主机信息，不可信；
- 混合部署场景（Nginx 与 MySQL、Java 共存）：预留 1–2 核给其他服务，比如 8 核机器可设为 worker_processes 6;。
选 auto 还是手动指定？
auto 是推荐起点，但不是万能解：
- worker_processes auto; —— Nginx 1.3.8+ 自动读取逻辑核心数，适合大多数物理机部署；
- 容器环境必须显式限定：比如限制了 2 vCPU，就写 worker_processes 2;，否则 auto 可能取到宿主机数值；
- 高 I/O 场景（静态文件、反向代理为主）：1～4 个进程常已足够，不需强求等于核心数；
- CPU 密集型（启用了大量 SSL/TLS、gzip、Lua 脚本）：建议贴近物理核心数，避免频繁调度损耗。
绑定 CPU 核心提升缓存效率
光设进程数不够，还要让每个 worker 稳定落在固定核心上，减少跨核缓存失效：
- 四核机器示例：worker_cpu_affinity 0001 0010 0100 1000;（每位对应一个核心，从右往左编号）；
- 支持 auto 绑定（Nginx 1.9.10+）：worker_cpu_affinity auto;，更简洁可靠；
- 注意：该指令需与 worker_processes 同级，放在 main 块内，且仅在 Linux 生效。
配套资源必须同步调优
worker_processes 单独调高没用，会卡在系统瓶颈上：
- 每个 worker 的连接上限由 worker_connections 控制，总并发 ≈ 进程数 × 连接数；
- 系统级文件描述符限制必须放宽：ulimit -n 65536（需在 nginx 启动前生效）；
- 建议在 events 块中明确指定高效事件模型：use epoll;（Linux 默认，但显式写出更稳妥）；
- 通过 worker_rlimit_nofile 提升单 worker 文件句柄上限，与 worker_connections 匹配。
