启用 worker_cpu_affinity 可让 Nginx 每个 worker 进程绑定指定 CPU 核心，减少上下文切换与缓存失效，提升高并发下的响应稳定性与吞吐量；需配合 worker_processes 正确配置，推荐多核场景使用 auto（1.9.10+），并通过 ps、taskset 等命令验证绑定效果。
启用 worker_cpu_affinity 可让 Nginx 的每个 worker 进程绑定到指定 CPU 核心，减少上下文切换和缓存失效，从而提升高并发下的响应稳定性和吞吐量。
理解 worker_cpu_affinity 的作用机制
Linux 调度器默认会动态迁移进程到空闲 CPU，但频繁迁移会导致 L1/L2 缓存冷启动、TLB 刷新，增加延迟。通过显式绑定，使每个 worker 长期运行在固定核心上，提升 CPU 缓存命中率和指令预取效率。尤其在多核 NUMA 架构下，还能避免跨节点内存访问开销。
正确配置 worker_cpu_affinity 的方法
需配合 worker_processes auto 或明确设置进程数，并确保 CPU 核心数 ≥ worker 数量：
- 双核服务器（2 个 worker）：
worker_cpu_affinity 01 10; - 四核服务器（4 个 worker）：
worker_cpu_affinity 0001 0010 0100 1000; - 八核服务器（8 个 worker）：
worker_cpu_affinity 00000001 00000010 ... 10000000; - 若使用
worker_processes auto，推荐写法：
worker_cpu_affinity auto;（Nginx 1.9.10+ 支持，自动按逻辑核顺序分配）
验证绑定是否生效
重启 Nginx 后，用以下命令确认绑定状态：
- 查看 worker 进程 PID：
ps -eo pid,args,psr | grep 'nginx: worker' - 检查 CPU 亲和性掩码：
taskset -cp <PID> - 观察
/proc/<PID>/status中的CapBnd和CPUs_allowed_list字段（更底层）
注意：若看到多个 worker 显示同一 CPU ID，说明配置有误或核心数不足。
注意事项与常见误区
- 仅在多核且负载较高的场景下收益明显；单核或低并发时无必要
- 不要将多个 worker 绑定到同一核心（如
01 01），会造成争抢 - 虚拟机中需确认宿主机已暴露完整 CPU topology，否则
auto可能误判 - 开启后建议关闭
worker_rlimit_nofile以外的过度调优项，避免干扰调度器
