worker_processes 应设为CPU物理核心数以平衡调度与并行，NUMA架构下必须用auto并配合worker_cpu_affinity auto；仅在I/O或SSL瓶颈时可适度超配，且需协同调优worker_connections和events配置。
worker_processes 直接决定 Nginx 能否有效榨干服务器的 CPU 和 I/O 资源，但它不是“越多越好”，而是要匹配硬件拓扑和实际负载特征。
worker_processes 本质是进程调度粒度
每个 worker 进程独立运行、互不阻塞，由内核调度到 CPU 上执行。主进程只管管理，不处理请求——真正干活的是这些 worker。所以进程数影响的是：谁来抢连接、谁来跑 SSL 解密、谁来读磁盘文件、谁来压缩响应。
- 设为 1：适合低流量、单核 VPS 或纯反向代理（后端强）场景，省资源但无法并行
- 设为 CPU 物理核心数：常规高并发 HTTP 服务的起点，平衡调度开销与并行能力
- 设为逻辑核心数（含超线程）：对纯计算型任务（如大量 gzip）可能有收益，但需实测，容易引发上下文切换抖动
NUMA 架构下必须用 auto
双路/四路服务器普遍存在 NUMA 拓扑——每个 CPU 插槽配专属内存通道。若手动写死 worker_processes 32，很可能一半 worker 跑在远端节点上，访问内存延迟翻倍，缓存命中率骤降，QPS 反而腰斩。
- ✅ 正确做法：
worker_processes auto;—— Nginx 1.3.8+ 自动识别 NUMA 节点，均匀分发 worker 到本地内存组 - ✅ 配套启用：
worker_cpu_affinity auto;—— 自动为每个 worker 绑定同一 NUMA 节点内的连续核心 - ⚠️ 验证方式：启动后执行
ps -eo pid,psr,comm | grep nginx，观察 CPU 编号是否自然分簇（如 0–15 和 32–47），而非散落在 0–63
什么情况下可以突破 CPU 核心数？
不是靠“堆进程”，而是填补瓶颈类型：
-
大量小文件 + 内存不足：文件总大小远超 RAM，磁盘 I/O 成瓶颈。增加 worker 数可提升并发读盘能力（注意：需配合
directio或调优 page cache） - 重度 SSL/TLS + 多核：RSA/ECC 密钥交换、证书链验证、TLS 1.3 handshake 等操作吃 CPU，多 worker 可分散加密负载
- 混合负载（CPU + I/O）：比如同时做 gzip 压缩（CPU）和静态文件传输（磁盘 I/O），实测中 worker_processes = CPU 核心数 × 1.5～2 有时更稳
别忽略配套限制
worker_processes 单独调高没用，必须协同调整：
-
worker_connections：每个 worker 能 hold 的连接数，受系统ulimit -n限制，建议 ≥65535 -
events { use epoll; }：Linux 下必须启用 epoll，否则高并发时 select/poll 效率断崖下跌 -
multi_accept on;：让一个 worker 尽可能一次 accept 多个就绪连接，减少惊群
