应设为CPU物理核心数，因每个worker进程独占一核可避免上下文切换、缓存失效与惊群效应，匹配其单线程事件驱动模型；超线程场景优先按物理核数配置，auto模式需加兜底限制。
将 worker_processes 设为 CPU 核心数，核心依据是让每个工作进程独占一个物理核心，实现真正的并行处理，避免资源争抢与调度开销。
匹配事件驱动模型的执行单元需求
Nginx 的每个 worker 进程是单线程、异步非阻塞的，它靠 epoll/kqueue 等机制高效轮询 I/O 事件。这种模型天然适合“一个进程绑定一个 CPU 核心”——无需线程切换，不共享执行上下文，能最大化利用 L1/L2 缓存局部性，降低缓存失效频率。
- 设得过少（如固定为 1），其余核心空闲，CPU 利用率低，高并发时请求排队
- 设得过多（远超核心数），内核频繁做进程调度，上下文切换耗 CPU，反而拖慢响应
规避惊群效应与锁竞争
多个 worker 共享监听 socket，当新连接到达时，所有 worker 都可能被唤醒去抢 accept（即“惊群”）。虽然 Nginx 1.9.1+ 默认启用 accept_mutex 缓解该问题，但 worker 数量远超核心数时，争抢概率仍上升，导致部分进程空转、负载不均。
- 每个 worker 独占一核，配合
worker_cpu_affinity绑定后，可显著减少跨核中断和 cache line bouncing - 配置文件中若未显式关闭
accept_mutex（默认 on），worker 数与核心数一致是最稳妥的平衡点
内存与资源开销呈线性增长
每个 worker 进程会加载完整配置、维护独立的连接池、缓存结构、SSL 会话缓存等。进程数量翻倍，内存占用几乎翻倍，文件描述符消耗也同步增加。
- 例如 8 核机器设为 16 个 worker，总内存占用可能多出 30%～50%，但 QPS 不升反降 5%～15%
- 尤其在反向代理或启用 gzip/Lua 的场景下，每个 worker 的内存 footprint 更大，盲目扩容得不偿失
物理核心优先于逻辑核心（含超线程）
超线程（HT）提供的是共享执行单元的“伪核心”，对 Nginx 这类 I/O 密集型服务增益有限。实际压测表明：4 物理核 + HT（共 8 逻辑核）的机器，设 worker_processes 4 通常比设为 8 更稳定、尾延迟更低。
- 查看物理核心数推荐用：
lscpu | grep "Core(s) per socket" && lscpu | grep "Socket(s)"，相乘得出 -
nproc返回的是逻辑核数，worker_processes auto默认按此设置，生产环境建议手动限定为物理核数或加兜底
