worker_processes 应设为物理CPU核心数，而非逻辑核数或auto盲目取值；容器环境须按cgroups实际vCPU配额显式设置，并配合worker_cpu_affinity绑核、worker_rlimit_nofile调优及worker_connections合理配置，才能真正提升CPU利用率。
worker_processes 直接决定 Nginx 能否有效利用 CPU，设少了核心空转，设多了反而引发调度争抢、上下文切换激增和缓存失效——它不是并发能力的“加速器”，而是资源匹配的“校准器”。
配多少才合适：看物理核，不看逻辑数
多数生产场景应设为物理 CPU 核心数，而非超线程后的逻辑核数。比如 4 物理核 + 超线程 = 8 逻辑核，实测中设为 4 往往比设为 8 缓存命中率更高、cs（上下文切换）更低。原因在于：Nginx 每个 worker 独立维护 SSL 缓存、连接状态和内存缓冲区，两个 worker 若被调度到同一物理核的两个逻辑线程上，会激烈争抢 L1/L2 缓存和执行单元。
- 查物理核数用：
lscpu | grep "Core(s) per socket"（例如输出 “2 sockets × 16 cores” 即 32 物理核） - I/O 密集型服务（静态分发、反向代理）：4～8 个常已足够，再增收益递减
- CPU 密集型任务（HTTPS 加解密、gzip_static）：优先按物理核设，并监控
vmstat 1中的 cs 值是否异常升高
auto 不是万能解：容器里尤其危险
worker_processes auto; 实际调用 sysconf(_SC_NPROCESSORS_ONLN)，等价于 nproc，但它完全不感知 cgroup 限制、NUMA 拓扑或虚拟化配额。在 Kubernetes 中若只分配了 2 个 vCPU，auto 仍可能拉起宿主机全部 64 个 worker，导致静默降级甚至 OOM。
- 容器部署必须显式写：
worker_processes 2;，与resources.limits.cpu: "2"严格对齐 - OpenVZ 或某些云平台中
nproc固定返回 1，auto 实际退化为单进程，需手动覆盖 - 必须配合
worker_cpu_affinity auto;（Nginx ≥ 1.12.0），否则即使进程数对了，也大概率被内核调度到同一核上
光设进程数没用：三重配套缺一不可
worker_processes 只是“并行宽度”的起点，真正发挥效能需系统级协同：
-
绑核才生效：不启用
worker_cpu_affinity，多个 worker 可能被动态迁移到同一核心，导致 TLB 刷新频繁、L2 缓存预热失效；四核机器示例：worker_cpu_affinity 0001 0010 0100 1000; -
放开句柄上限：每个 worker 独立消耗文件描述符，
worker_rlimit_nofile 65536;必须配ulimit -n 65536（在 nginx 启动前生效） -
控制单 worker 负载：
worker_connections过高（如 65536）易致内存碎片和缓冲区膨胀；一般建议 2048～4096，再结合net.core.somaxconn≥ 该值
怎么验证真有效：别只看配置文件
改完配置后，关键看三件事：
- 进程数是否匹配：
ps aux | grep nginx | grep -v grep | wc -l（应等于你设的值） - 是否真绑核：
taskset -cp $(pgrep -f "nginx: worker")查每个 worker 实际运行的 CPU ID - 是否触发瓶颈：
netstat -s | grep "listen overflows"看是否有连接被内核丢弃；nginx_stub_status中 Accepts/Handled 比值应接近 1
