worker_processes 应设为物理cpu核心数，必须配合worker_cpu_affinity绑定核心，否则进程可能被调度至同一核而丧失多核优势；容器环境须按vcpu配额显式设置，并同步调优worker_rlimit_nofile及系统限制。
worker_processes 不能单独调优，必须和 CPU 绑定（worker_cpu_affinity）配合使用，否则进程可能被内核随机调度到同一核心，失去多核优势。
worker_processes 数值怎么定
应等于服务器物理 CPU 核心数，不是逻辑核或超线程数。例如 4 物理核 + 超线程共 8 逻辑 CPU，推荐设为 4；32 物理核服务器就设为 32。可用以下命令确认：
- lscpu | grep "Core(s) per socket" 查每颗 CPU 的物理核数
- nproc --all 查总逻辑核数（仅作参考，不直接采用）
- 容器或 Kubernetes 环境中，必须按实际分配的 vCPU 数显式设置，如 resources.limits.cpu: "2" → 就写 worker_processes 2;
worker_cpu_affinity 必须同步开启
只设对进程数但不绑核，等于没优化。绑定后每个 worker 固定运行在专属核心，减少缓存失效、TLB 刷新和跨 NUMA 访问延迟。
- 四核机器：写 worker_cpu_affinity 0001 0010 0100 1000;
- 八核及以上推荐用 worker_cpu_affinity auto;（Nginx ≥ 1.9.10），自动错开超线程对，优先分配物理核
- 掩码组数必须与 worker_processes 数量严格一致，否则 Nginx 启动失败或部分 worker 不生效
配套系统限制要一起改
光有进程数和绑核还不够，文件描述符上限卡住，再多 worker 也打不开连接。
- 在 nginx.conf main 块加：worker_rlimit_nofile 65535;
- /etc/security/limits.conf 中为 nginx 用户设：nginx soft nofile 65535 和 nginx hard nofile 65535
- 确保 systemd 启动时加载限制（如添加 LimitNOFILE=65535 到 nginx.service）
怎么验证是否真绑上了
别只信配置，要看运行时状态：
- 查 worker 进程 PID：pgrep -f "nginx: worker"
- 查绑定情况：taskset -cp
（输出类似 “pid 12345's current affinity list: 0” 表示绑在 core 0） - 观察各核负载：mpstat -P ALL 1，应看到利用率大致均衡，无单核打满、其余空闲现象
