worker_processes 应设为逻辑cpu核心数，推荐使用 auto；需配合 worker_cpu_affinity 绑定cpu、调高 ulimit -n 和 worker_connections，并验证配置后重载。
worker_processes 直接决定 Nginx 启动多少个独立工作进程，是影响 CPU 利用率和并发处理能力的最底层参数。设得合理，多核资源就被真正“跑起来”；设得不对，要么单核忙死、其余闲着，要么进程太多互相抢资源，反而更慢。
核心数匹配是最稳妥的选择
一台物理机或云主机有几颗逻辑 CPU 核心（含超线程），就让 worker_processes 等于这个数。比如 4 核 8 线程，推荐设为 8；2 核虚拟机，就设为 2。Nginx 1.3.8+ 支持 worker_processes auto;，它会自动读取 nproc 输出并设置，省去手动查核数的步骤，也避免容器里误读宿主机核数的问题。
- 查当前逻辑核数：运行
nproc或lscpu | grep "CPU(s):" - 配置写在 nginx.conf 最外层（main 块），不能放在 http 或 server 里
- 设为 1 是常见误区——所有请求串行排队，高并发下响应延迟飙升
过大过小都会拖慢整体性能
worker_processes 不是越大越好。超过 CPU 核心总数后，系统调度开销上升，进程频繁切换，锁竞争加剧，实测 QPS 反而可能下降 5%～15%。尤其在短连接、高频率请求场景下更明显。
- 设太小：无法摊薄负载，单进程成为瓶颈
- 设太大：每个 worker 都要加载完整配置、缓存、连接结构体，内存占用线性增长
- 惊群效应虽被 accept_mutex 缓解，但未根除——多个 worker 同时被唤醒争抢新连接
配合 CPU 绑定提升缓存效率
光设对进程数还不够。启用 worker_cpu_affinity 能把每个 worker 固定绑到一个 CPU 核上，减少跨核迁移带来的 L1/L2 缓存失效，指令执行更连续，尤其在高负载下效果可测。
- 双核：worker_cpu_affinity 01 10;
- 四核：worker_cpu_affinity 0001 0010 0100 1000;
- Nginx 1.9.10+ 支持 worker_cpu_affinity auto;，自动分配，推荐使用
必须同步检查关联参数
worker_processes 的效果依赖配套设置。它和 worker_connections 共同决定理论最大连接数（worker_processes × worker_connections），但这个数字会被系统级限制卡住。
- 调高 ulimit -n（如设为 65536），确保每个 worker 能打开足够文件描述符
- 在 events 块中配好 worker_connections（建议 ≥10240）
- 加一句 worker_rlimit_nofile 65535，让单个 worker 显式继承上限
- 修改后务必执行
nginx -t验证语法，再nginx -s reload生效
