worker_processes auto;是稳妥起点，但必须同步确认物理核心数、绑定cpu亲和性、放开文件描述符限制及匹配epoll事件模型，否则无法真正用满多核性能。
worker_processes 直接设为 auto 就行，但别以为设完就完事了
绝大多数情况下，worker_processes auto; 是最稳妥的起点。Nginx 1.3.8+ 会读取系统逻辑 CPU 核数（比如 nproc 输出 8，就启 8 个进程），省去手动查核、写死数字的麻烦。但注意：这仅是“启动数量”，不等于“真正用满多核”。如果你在容器里跑 Nginx，auto 可能误读宿主机核数（比如 Pod limits.cpu: "2"，却按宿主机 64 核起 64 个 worker），结果资源被内核强行 throttled，QPS 不升反降。
物理核心数才是关键，尤其在双路/NUMA 服务器上
别只看 nproc 或 lscpu | grep "CPU(s)" 的数字——那是逻辑核（含超线程）。Nginx worker 是重量级进程，绑在同一物理核的两个逻辑核上会争 L2 缓存、抬高 TLB miss 率。真实物理核总数得算：lscpu | grep -E "Core\(s\) per socket|Socket\(s\)"，再相乘。例如 2 sockets × 16 cores = 32 物理核。双路服务器还要留意 NUMA：跨节点访问远端内存延迟高，建议按 NUMA 节点分组配 worker（如每个节点 16 核，就设 16 个 worker 并绑定到对应节点 CPU）。
不配 worker_cpu_affinity，worker_processes 再对也白搭
Linux 调度器默认不保证进程固定在某核运行。多个 worker 挤在一个核上会导致 SSL session cache 失效、共享内存锁竞争加剧、上下文切换飙升——实测 QPS 可跌 5%～15%。Nginx ≥ 1.9.10 推荐直接写：worker_cpu_affinity auto;，它能自动跳过超线程对称核，优先绑定独立物理核。若需精细控制（比如 4 核物理机），手动写：worker_cpu_affinity 0001 0010 0100 1000;（位图从右往左对应 core 0–3）。验证是否生效：ps -eo pid,psr,comm | grep nginx，看每个 worker 的 PSR 列是否稳定落在不同编号上。
配套三件事不做，worker_processes 就是纸面并发
单改 worker_processes 几乎无效，必须同步放开三处瓶颈：
-
worker_rlimit_nofile 65535;—— 写在 nginx.conf main 块，告诉 Nginx 自己能打开多少文件 -
events { worker_connections 4096; use epoll; }—— 每个 worker 连接数建议 2048～8192，use epoll;必须显式声明，否则高并发下性能断崖下跌 - 系统级 ulimit：在
/etc/security/limits.conf加两行：nginx soft nofile 65536和nginx hard nofile 65536，再确保启动 Nginx 的用户（如nginx）实际生效（可sudo -u nginx bash -c 'ulimit -n'验证）
最容易被忽略的是：这些配置之间有依赖关系——worker_processes × worker_connections 要 ≤ 系统 ulimit -n，否则你会看到 accept() failed (24: Too many open files) 报错，或更糟：静默降级，连接被丢弃却不报错。
