worker_processes最佳实践是匹配CPU物理核心数、避免调度开销、配合worker_cpu_affinity与系统资源限制；首选worker_processes auto;，Nginx 1.3.8+自动适配物理核数，并需同步调优worker_rlimit_nofile、ulimit及内核参数。
worker_processes 的最佳实践核心是“匹配物理核心数、避免调度开销、配合系统资源”，不是调得越高越好，而是让每个进程稳稳跑在一个 CPU 核上。
首选 auto，而不是硬写数字
直接写 worker_processes auto; 是最稳妥的生产配置。Nginx 1.3.8+ 会自动读取当前环境的 CPU 物理核心数，并启动对应数量的 worker 进程。这个机制在以下场景依然可靠：
- 物理服务器：auto = 物理核心数（如 8 核 → 启 8 个进程）
- Docker 容器：官方镜像（如 nginx:alpine）内置脚本会解析 cgroups 的 cpu quota，auto 仍能反映容器实际配额
- Kubernetes Pod：若设置了
resources.limits.cpu，需确认基础镜像支持 cgroups v2 检测，否则可能误读为宿主机核数
手动设置时盯准物理核心数，不是逻辑线程数
超线程（如 8c16t）对 Nginx 这类 I/O 密集型服务增益有限，反而可能增加上下文切换负担。应以物理核心为准：
- 查物理核心数命令：
grep -c 'core id' /proc/cpuinfo或nproc --all - 8 物理核 → 设为 8；16 物理核 → 设为 16
- 不建议设为 1（仅限调试），也不建议超过物理核数的 1.5 倍（如 32 核设 64）
- 若服务器还跑数据库等重负载服务，可预留 1–2 核，例如
worker_processes $(nproc --all)-2;
必须搭配 worker_cpu_affinity 绑定 CPU 核心
只设进程数不够，还要让每个进程“钉”在固定核心上，减少跨核缓存失效：
- 该指令必须放在全局块（main context），仅 Linux 有效
- 双核写法：
worker_cpu_affinity 01 10; - 四核及以上推荐：
worker_cpu_affinity auto;（Nginx 1.9.10+ 支持） - 未启用时，高并发下 L1/L2 缓存命中率下降，延迟波动更明显
不能孤立调优，要同步检查三类配套限制
worker_processes 的效果依赖底层资源支撑，缺一不可：
-
worker_rlimit_nofile：全局块中设置，值应 ≥ 单个 worker 的
worker_connections（如 events 块设了 8192，则这里至少设 8192） -
系统 ulimit -n：应 ≥
worker_processes × worker_connections × 1.2，否则会出现 “too many open files” 错误 -
Linux 内核参数：确保
/proc/sys/net/core/somaxconn足够大（建议 ≥65535），避免连接队列溢出
