worker_processes必须配合cpu绑定才能发挥多核性能；应设为物理核心数并配置worker_cpu_affinity，容器中按vcpu数设置，numa架构需分节点均分，同时调优文件描述符、连接数和事件模型。
worker_processes 不能单独设置，必须和 CPU 绑定配合才能真正发挥多核性能。设得对但不绑核，进程仍可能被调度到同一核心，缓存争抢、TLB 刷新、跨 NUMA 访问等问题反而会拖慢响应。
先确认物理核心数，不是逻辑核或超线程数
Nginx 是 I/O 密集型服务，物理核心才是真实计算单元。超线程（HT）只是并发执行能力，共享 L1/L2 缓存，两个 worker 绑在同一物理核的不同逻辑 ID 上，容易互相干扰。
用这两条命令查清真实拓扑：
-
lscpu | grep -E "Core\(s\) per socket|Socket\(s\)"→ 算出物理核总数（例如 2 sockets × 16 cores = 32 物理核） -
nproc --all→ 查逻辑核总数（仅作参考，不直接采用）
设 worker_processes 值要匹配物理核数
- 32 物理核 →
worker_processes 32; - 容器环境按实际分配的 vCPU 数设（如
resources.limits.cpu: "4"→ 就写worker_processes 4;） - 混合部署（如 Nginx + 数据库共存）可预留资源：
worker_processes $(nproc --all)-2;（需在启动脚本中执行） - 最稳妥写法是
worker_processes auto;（Nginx ≥ 1.3.8 支持），但它在容器里可能读错宿主机核数，所以生产环境建议显式指定。
必须配 worker_cpu_affinity 才算完成绑定
只改进程数不绑核，等于没调优。绑定后每个 worker 固定运行在专属物理核上，SSL 缓存、共享内存锁、文件元数据等才能稳定驻留本地缓存。
- 推荐通用写法：
worker_cpu_affinity auto;（Nginx ≥ 1.9.10 支持，自动跳过超线程对称核，优先分配物理核） - 手动写掩码时注意位序：最右 bit 对应 CPU 0，从右往左依次为 bit 0、bit 1…
例如 4 核：worker_cpu_affinity 0001 0010 0100 1000;
8 核更安全写法：worker_cpu_affinity 01 02 04 08 10 20 40 80;（十六进制，不易数错） - NUMA 架构（如双路服务器）必须分节点均分：先
numactl --hardware查布局，再按节点分别配置两组worker_cpu_affinity，避免跨节点访问远端内存。
配套必须调优，否则“有核无粮”
- 文件描述符上限：
worker_rlimit_nofile 65535;（同时确保系统级ulimit -n ≥ 65535，修改/etc/security/limits.conf） - 单进程连接数：
events { worker_connections 4096; }，总并发 ≈worker_processes × worker_connections - 事件模型固定写：
use epoll;，开启批量收包：multi_accept on;，旧版本需关惊群：accept_mutex off;
验证是否真绑上了
重启 Nginx 后执行：
-
ps -eo pid,psr,comm | grep nginx→ 看每个 worker 的 PSR 列是否稳定落在不同 CPU 编号上 -
taskset -cp <pid></pid>→ 输出应与你配置的掩码一致（如pid 12345's current affinity list: 0表示绑定到 core 0）
若 PSR 频繁跳变，说明绑定失败——常见原因是掩码组数与worker_processes数量不匹配，或位数超出系统逻辑 CPU 总数。
