worker_processes 的合理取值应等于CPU物理核心数；例如2路×12核=24核则设为24，超线程仅作参考，I/O密集型可试1.2～1.5倍但需压测，CPU密集型须严格匹配物理核数，并配合worker_cpu_affinity auto优化调度。
worker_processes 的合理取值，核心取决于服务器的 CPU 物理架构，而非内存、磁盘或带宽等其他硬件。它本质是调度单位，直接映射到 CPU 资源的分配逻辑上。
CPU 物理核心数是首要依据
每个 worker 进程默认独占一个物理 CPU 核心运行最稳定高效。逻辑处理器数（含超线程）仅作参考，不建议直接设为该值：
- 用 lscpu | grep "Core(s) per socket" && lscpu | grep "Socket(s)" 相乘得出物理核心总数
- 例如：2 路 × 12 核 = 24 物理核 → 初始配置 worker_processes 24
- 若系统显示 48 个逻辑 CPU（启用了超线程），仍以 24 为基准，避免多个 worker 挤在同一物理核争抢睿频资源
CPU 是否启用超线程（HT/SMT）影响决策边界
超线程能提升吞吐但不增加真实算力，反而可能加剧缓存争用和频率波动：
- 纯 I/O 密集型（如静态文件服务、高命中缓存代理），可尝试设为物理核数的 1.2～1.5 倍（如 24 核试 28～32），需压测验证
- CPU 密集型（大量 SSL 加解密、Lua 运算、gzip 压缩），严格匹配物理核数，禁用超线程干扰
- 容器或云主机中，若 vCPU 是共享资源（非独占物理核），应以 cgroup 限制为准，而非 /proc/cpuinfo 显示值
CPU 睿频与温度功耗约束需间接应对
worker_processes 本身不感知睿频，但配置不当会放大其副作用：
- 进程数超过物理核数 + 未绑定 CPU 亲和性 → 多个 worker 被调度到同一物理核，触发降频
- 正确做法：设为物理核数 + 启用 worker_cpu_affinity auto（Nginx ≥1.9.10），自动跳过超线程逻辑核
- 配合 reuseport 和关闭 accept_mutex，把连接分发前置到内核，减少因调度延迟导致的负载抖动
内存与文件描述符是配套约束项
它们不决定 worker_processes 取值，但限制其实际效果：
- 每个 worker 加载完整配置、维护连接结构体，内存占用随进程数线性增长；10 万空闲 Keep-Alive 连接约需 2.5MB 内存
- worker_connections 乘积受系统级 ulimit -n 和 Nginx 的 worker_rlimit_nofile 双重限制
- 总并发能力 = worker_processes × worker_connections，但必须确保系统资源（内存、fd、端口）支撑该理论值
