直接设为auto最稳妥，但需结合物理核数（非逻辑核）、worker_cpu_affinity auto、worker_rlimit_nofile 65535、epoll事件模型及multi_accept等协同调优，否则单改worker_processes无效。
直接设为 auto 是最稳妥的做法，它会自动匹配 CPU 逻辑核心数；但要真正发挥多核性能，不能只改这一个参数，得结合硬件真实拓扑、系统限制和业务类型来协同配置。
先搞清物理核 vs 逻辑核，别被超线程带偏
超线程（HT）会让一个物理核心暴露成两个逻辑 CPU，比如 8 物理核 + HT = 16 逻辑核。但 Nginx 的 worker 进程是重量级的，共享 L1/L2 缓存时容易争抢：
- 查物理核总数：运行
lscpu | grep -E "Core\(s\) per socket|Socket\(s\)"，相乘即得（例如 2 sockets × 6 cores = 12 物理核） - 查逻辑核总数：运行
nproc或lscpu | grep "CPU(s):" - 一般场景优先按物理核数起步（如 12 物理核 →
worker_processes 12），高并发小包场景可压测后尝试逻辑核数
用 auto 模式，但要加兜底或手动覆盖
worker_processes auto; 在 Nginx 1.3.8+ 中默认读取逻辑核数，方便又少出错。但在生产环境建议配合约束：
- 云主机或容器中，
auto可能读到宿主机核数（比如容器只分了 2 核，却起了 32 个进程），应显式设为预期值：worker_processes 2; - 混合部署场景（如 Nginx 和数据库共存），可预留资源：
worker_processes $(nproc --all)-2;（需在启动脚本中执行） - 若用
auto，推荐同时启用worker_cpu_affinity auto;（Nginx ≥ 1.9.10），它会自动跳过超线程对称核，优先绑定物理核
必须配套调优，否则 worker 数再多也白搭
worker 进程数只是“车道数”，没有足够“车流容量”和“路权规则”，并发上不去：
-
文件描述符要够：在 main 块设
worker_rlimit_nofile 65535;，并确保系统级ulimit -n≥ 该值（修改/etc/security/limits.conf） -
每个进程连接上限要配好：在
events { }块中设worker_connections 4096;或更高，总并发 ≈worker_processes × worker_connections -
事件模型要选对：Linux 下固定写
use epoll;，旧版本还需显式关闭惊群：accept_mutex off;，并开启批量收包：multi_accept on;
验证是否真绑上了 CPU 核心
配置完别急着上线，用命令确认绑定是否生效：
- 重启 Nginx 后执行：
ps -eo pid,psr,comm | grep nginx，看每个 worker 的 PSR 列是否稳定落在不同 CPU 编号上 - 检查单个进程亲和掩码：
taskset -cp <pid></pid>，输出应与你配置的二进制掩码一致（如0001对应 CPU 0） - 若 PSR 频繁跳变，说明绑定失败——常见原因是
worker_processes和worker_cpu_affinity数量不匹配，或掩码位数超出系统逻辑 CPU 总数
