worker_processes 需按物理核心数（非逻辑核）配置并配合 worker_cpu_affinity 绑定，否则易引发缓存失效与上下文切换激增；auto 仅读逻辑核数，不感知超线程、NUMA 或容器限制，生产环境应显式设置并验证。
worker_processes 不是简单设个数字就能提升性能的参数，它的效果高度依赖 CPU 架构、工作负载类型和系统调度行为。设得不准，轻则浪费资源，重则引发缓存失效、上下文切换激增，反而拖慢整体响应。
物理核心 vs 逻辑核心：别被超线程“骗”了
现代 CPU 普遍支持超线程（HT），一个物理核心暴露为两个逻辑 CPU。但它们共享 L1/L2 缓存、执行单元和前端总线。Nginx 的每个 worker 进程是独立内存空间 + 独立文件描述符表 + 独立 SSL 会话缓存，若两个 worker 被调度到同一物理核的两个逻辑核上，频繁竞争缓存行，会导致大量 cache miss。
- 计算密集型场景（如启用了 gzip_static 或大量 TLS 加密）→ 建议设为 物理核心数，避免执行单元争抢
- I/O 密集型场景（如静态文件分发、反向代理转发）→ 可设为 逻辑核心数，甚至 1.5 倍，让部分进程在等待磁盘或后端响应时，其他进程能继续处理新连接
- 查物理核心数命令：
nproc --all和lscpu | grep "Core(s) per socket"对比确认
CPU 绑定（worker_cpu_affinity）不是可选项
不绑定时，Linux 调度器会动态迁移 worker 进程，导致 CPU 缓存预热失效、TLB 刷新频繁、NUMA 跨节点访问延迟升高。尤其在高 QPS 场景下，这种开销会被显著放大。
- 4 核服务器示例：
worker_processes 4; worker_cpu_affinity 0001 0010 0100 1000;—— 每个 worker 固定运行在唯一核心上 - 8 核服务器若用 8 个 worker，可用
00000001 00000010 ... 10000000逐位掩码绑定 - 验证是否生效：
taskset -cp $(pgrep -f "nginx: worker")查看每个 worker 实际绑定的 CPU ID
进程数 ≠ 并发能力：它只是上限杠杆
worker_processes 决定了并发处理的“并行宽度”，但真正承载连接的是 worker_connections。两者共同决定理论最大连接数：worker_processes × worker_connections。然而这个值受三重限制：
-
系统级文件描述符上限：必须同步调大
fs.file-max和用户级ulimit -n，否则会出现 “too many open files” 错误 -
内核网络队列长度：
net.core.somaxconn必须 ≥ worker_connections，否则新连接在进入 Nginx 前就被内核丢弃 - 内存占用增长：每个连接平均消耗 10–20 KB 内存（含缓冲区、SSL 上下文等），8 个 worker × 65535 连接 ≈ 10 GB 内存，需提前评估
auto 并非万能：它只认逻辑核数，不识业务特征
worker_processes auto; 是便捷写法，但它只读取 /proc/cpuinfo 中的 processor 总数（即逻辑核），无法区分物理拓扑、NUMA 节点或当前负载倾向。生产环境建议显式配置，并配合 worker_cpu_affinity 使用。
- 双路 24 核 CPU（共 48 逻辑核）服务器，若跑纯静态服务，可设
worker_processes 48并完整绑定 - 同配置若跑高 TLS 开销的 API 网关，更优解可能是
worker_processes 24（物理核数）+ 精确绑定 + 提升worker_priority（谨慎使用） - 容器化部署需注意：cgroup 限制可能使
auto返回错误核数，务必通过cat /sys/fs/cgroup/cpuset.cpus.effective校验实际可用 CPU
