worker_processes 应设为物理核心数（非逻辑核），配合 worker_cpu_affinity 自动绑定、worker_rlimit_nofile 65535 和 epoll 事件模型，才能在负载均衡场景逼近吞吐极限。

要让 Nginx 在负载均衡网关场景下逼近吞吐极限，worker_processes 不是孤立调大的数字，而是需与 CPU 物理拓扑、流量模式和系统资源协同定值的核心参数。盲目设为“auto”或硬填逻辑核数，常导致缓存争抢、惊群效应或空转浪费。

先确认真实可用的物理核心数，而非逻辑核数

超线程（HT）会让 lscpu 显示双倍逻辑 CPU，但两个逻辑核共享同一物理核的执行单元和 L1/L2 缓存。在负载均衡这类高连接、中等计算强度的场景下：

• 优先按 物理核心数 设置 worker_processes，例如 4 物理核 + HT = 8 逻辑核 → 建议设为 worker_processes 4;
• 若后端 upstream 响应极快（如本地 Redis 或短路径缓存），且请求包小、频次极高，可尝试设为逻辑核数（如 8），但必须同步验证缓存命中率与 TLB miss 率是否恶化
• 运行 lscpu | grep -E "(Core|Socket|Thread)"，用 Core(s) per socket × Socket(s) 得出物理核总数

绑定策略必须匹配进程数，避免“配了等于没配”

worker_processes 和 worker_cpu_affinity 是一对强耦合配置。常见失效情形包括：

• 设了 worker_processes 8，却只写 worker_cpu_affinity 0001 0010 0100 1000;（仅 4 组掩码）→ 后 4 个 worker 退回到默认调度，失去控制
• 在 NUMA 架构服务器（如双路 Xeon）上未考虑节点亲和性，导致 worker 处理请求时频繁跨节点访问内存
• 推荐起步方案：worker_processes auto; + worker_cpu_affinity auto;（Nginx ≥ 1.9.10），它会自动跳过超线程对称核，优先分配物理核

配套三要素缺一不可，否则 CPU 绑定毫无意义

即使每个 worker 都独占一个物理核，若以下任一条件不满足，吞吐仍会被卡在瓶颈处：

• 文件描述符必须够用：设置 worker_rlimit_nofile 65535;，并确保系统级 ulimit -n ≥ 该值，否则连接数上不去，worker 长期空转
• 事件模型必须高效：Linux 下固定用 events { use epoll; worker_connections 65535; }，总并发能力 = worker_processes × worker_connections
• 避免 accept 锁串行化：Nginx ≥ 1.11.3 默认关闭 accept_mutex，旧版本务必显式写 accept_mutex off;；同时启用 multi_accept on;，让单个 worker 一次收多个就绪连接

验证是否真正生效，别信配置文件写了就算

重启 Nginx 后，用以下命令交叉确认：

• ps -eo pid,args,psr | grep 'nginx: worker' → 查看每个 worker 实际运行在哪颗 CPU（psr 列）
• taskset -cp → 显示该进程当前实际生效的 CPU 亲和掩码
• cat /proc//status | grep Cpus_allowed_list → 看内核允许范围是否与预期一致
• 若多个 worker 的 psr 值相同，或 Cpus_allowed_list 重叠，说明配置未加载或核心数不足