worker_processes 应设为物理cpu核心数而非逻辑核数，以避免超线程干扰、降低调度开销、提升缓存命中率；需结合部署环境（物理机/docker/k8s/老旧虚拟化）和业务类型（i/o或cpu密集型等）微调，并配套设置worker_cpu_affinity、worker_rlimit_nofile等参数。
worker_processes 应尽量贴近服务器真实可用的物理 CPU 核心数，不是越多越好，也不是简单照搬逻辑核数。核心目标是让每个 worker 进程稳定运行在一个物理核上，避免争抢、减少调度开销、提升缓存命中率。
先确认物理核心数，别被超线程带偏
超线程（HT）会让一个物理核暴露成两个逻辑 CPU，但 Nginx 的 worker 是重量级进程，共享 L1/L2 缓存，绑在同一物理核的两个逻辑核上反而容易互相干扰。
- 查物理核心总数：
lscpu | grep -E "Core\(s\) per socket|Socket\(s\)"，相乘即得（例如 2 sockets × 12 cores = 24 物理核） - 查逻辑核数（仅作参考）：
nproc或lscpu | grep "CPU(s):" - 常见误区：8c16t 机器默认设为 16 是错的，起点应是 8；若负载轻、连接短，4～6 也可能更稳
按部署环境选配置方式
auto 不是万能钥匙，不同环境要区别对待：
-
物理服务器：直接写
worker_processes auto;，Nginx 1.3.8+ 会读取逻辑核数，配合worker_cpu_affinity auto;（≥1.9.10）可自动跳过超线程对称核，优先绑定物理核 -
Docker 容器：若镜像支持 cgroups v2，auto 通常有效；否则建议显式设置，比如容器限制了 2 个 vCPU，就写
worker_processes 2; -
Kubernetes Pod：必须与
resources.limits.cpu: "2"严格对齐，写worker_processes 2;；若用 auto，需确认基础镜像支持 cgroups v2 检测，否则可能误读宿主机核数 -
OpenVZ 或老旧虚拟化平台：
nproc常固定返回 1，auto 会退化为单进程，必须手动覆盖
结合业务类型微调数值
物理核数只是起点，最终值要看实际负载特征：
- I/O 密集型（静态文件、高命中反向代理、缓存服务）：通常 1～4 个 worker 就够用，再多收益递减，甚至增加上下文切换
-
CPU 密集型（全站 HTTPS、实时 gzip 压缩、OpenResty 中大量 Lua 运算）：可设为物理核数，但要监控
vmstat 1中的cs（上下文切换）是否异常升高 - 混合或长连接场景（WebSocket、gRPC、上游响应慢）：内存和文件描述符压力大，建议设为物理核数的 1/2～3/4（如 16 核设 8～12）
-
资源共用服务器（Nginx 和数据库同机）：预留 1～2 个核，worker_processes 可设为
$(nproc --all) - 2
必须配套生效的关键参数
只改 worker_processes 没用，得一起调：
- 绑定核心：
worker_cpu_affinity auto;（推荐）或手动写掩码（如四核：0001 0010 0100 1000） - 放开句柄上限：
worker_rlimit_nofile 65535;，并同步调高系统级ulimit -n - 控制单进程连接数：
events { worker_connections 4096; }，过高易引发内存碎片 - 指定事件模型：
use epoll;（Linux），并开启multi_accept on;
配完别只信配置文件，用 ps -eo pid,psr,comm | grep nginx 看 PSR 列是否稳定落在不同 CPU 上，再看 error.log 是否提示 “using X processes”。不复杂但容易忽略。
