worker_processes应设为物理CPU核心总数，搭配worker_cpu_affinity auto及worker_rlimit_nofile、epoll等参数才能真正发挥多核性能。
直接在 nginx.conf 的最外层（main 块）设置 worker_processes，值应等于服务器**物理 CPU 核心总数**，不是逻辑核数，也不是“越多越好”。这是发挥多核性能的基础，但必须搭配核心绑定与资源限制才真正生效。
先确认真实物理核心数
别被超线程（HT）或容器虚拟核数误导：
- 执行
lscpu | grep -E "Core\(s\) per socket|Socket\(s\)"，相乘得出物理核总数（例如：2 sockets × 12 cores = 24） - 对比参考逻辑核数：
nproc --all或lscpu | grep "CPU(s):"（如 24 物理核 + HT = 48 逻辑核） - 容器/K8s 中需查 cgroup 限制：
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us和/cpu.cfs_period_us，算出实际分配的 vCPU 数
主区块中正确配置方式
在 nginx.conf 的 main 块（即 events { } 外、最顶层）写：
- 推荐显式指定 + 自动绑核：
worker_processes 24;（填你确认的物理核数）worker_cpu_affinity auto;（Nginx ≥ 1.9.10，自动跳过超线程对称逻辑核，绑定到不同物理核的第一个线程） - 若用
auto，仅限物理机且无资源限制场景：worker_processes auto;，但它默认读逻辑核数，云环境或容器中易误配，不建议生产直接用 - 混合部署（如 Nginx 与数据库同机）：预留 1～2 核，可写
worker_processes 22;（24 物理核 − 2）
必须同步生效的关键配套项
只改 worker_processes 几乎没用，以下参数必须一起配置：
-
worker_rlimit_nofile 65535;（main 块），并确保系统级ulimit -n≥ 该值 -
events { use epoll; worker_connections 4096; multi_accept on; }（Linux 必须显式写use epoll） - 若启用了 SSL/TLS 终止或大量 Lua 运算，可将
worker_processes微调为物理核数 +1～2；若主要是静态文件或反向代理，设为 1～4 可能更稳
验证是否真按预期运行
重载配置后立即检查：
-
ps -eo pid,psr,comm | grep nginx：每个 worker 的 PSR 列应稳定分布在不同 CPU 编号上（如 0、1、2、3…），不跳变 -
taskset -cp <pid></pid>：确认进程亲和掩码与物理核分布一致 -
htop观察各 worker 的 CPU 占用是否大致均衡，总和接近N × 100%（N 为 worker 数）
