启用worker_cpu_affinity可让nginx每个worker进程绑定指定cpu核心，减少上下文切换与缓存失效，提升高并发下响应稳定性与吞吐量；需配合worker_processes合理设置、确认物理拓扑、避免超线程争抢，并通过ps和taskset验证绑定效果。

要让 Nginx 在负载均衡网关场景下逼近性能极限，worker_cpu_affinity 不是“开了就快”的开关，而是需要和 CPU 架构、核心拓扑、流量特征协同调优的关键环节。它真正起效的前提是：worker_processes 已合理设置、系统无 I/O 或锁瓶颈、且绑定策略匹配物理层实际能力。

先摸清硬件真实拓扑，别被逻辑核数带偏

超线程（HT）会让 lscpu 显示双倍逻辑 CPU，但两个逻辑核共享同一物理核的 L1/L2 缓存和执行单元。盲目按 8 个逻辑核配 8 个 worker 并全绑不同核，反而可能引发资源争抢。

• 运行 lscpu | grep -E "(CPU\(s\)|Core|Socket|Thread)"，确认物理核数（Core(s) per socket × Socket(s)）与线程数（Thread(s) per core）
• 若 HT 开启（Thread(s) per core = 2），优先把 worker 绑定到不同物理核，而非所有逻辑核。例如 4 物理核 + HT = 8 逻辑核，可设 worker_processes 4 + worker_cpu_affinity auto，Nginx 1.9.10+ 会自动跳过超线程对称核，避免缓存干扰
• BIOS 中关闭 HT 后再测，有时吞吐更稳——尤其当 upstream 是高延迟或 TLS 计算密集型时

用 auto 模式起步，再按需收紧范围

手动写十六进制掩码易出错，也难适配云环境（如 vCPU 数量虚高但物理资源受限）。auto 是更健壮的起点：

• worker_cpu_affinity auto; —— 自动按物理核分配，每个 worker 独占一个物理核，L1/L2 缓存局部性最优
• worker_cpu_affinity auto 00001111; —— 限制只使用前 4 个逻辑 CPU（对应前 2 或 4 物理核），适合容器中限定资源配额的场景
• 不建议混用：比如 worker_processes 8 但只给 4 个掩码值，剩余 worker 会 fallback 到默认调度，失去控制意义

配合其他硬指标，防止 CPU 绑定失效

CPU 亲和性只是拼图一角。若以下任一条件不满足，绑定再准也白搭：

• worker_rlimit_nofile 必须设够：至少等于 ulimit -n，否则连接数上不去，worker 长期空转，CPU 绑定毫无意义
• events { use epoll; worker_connections 65535; } —— epoll 是 Linux 下高并发事件驱动基石；worker_connections 要与 worker_processes 协同，总连接能力 = 两者乘积
• upstream 连接复用：开启 keepalive（如 keepalive 32; keepalive_requests 1000;），避免频繁建连消耗 CPU，让绑定后的计算资源专注分发逻辑

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

启动后必须实测确认绑定状态：

• ps -eo pid,args,psr | grep nginx | grep -v grep → 查看每个 worker 进程当前运行在哪颗 CPU（PSR 列），应呈离散分布
• taskset -cp $(pgrep -f "nginx: worker") → 批量检查每个 worker 允许运行的 CPU 列表，输出应与配置严格一致
• 若多个 worker 显示相同 PSR 值，常见原因是 worker_processes = 1，或掩码全为 1（如 11 11），需回查配置上下文