启用worker_cpu_affinity可让Nginx每个worker进程绑定指定CPU核心，减少缓存失效、TLB刷新和NUMA访存开销；需先确认逻辑CPU数、合理配置掩码或使用auto模式，并配合multi_accept、worker_connections等参数协同优化。
直接配置 worker_cpu_affinity 能让每个 Nginx worker 进程固定运行在指定 CPU 核心上，减少跨核调度带来的缓存失效、TLB 刷新和 NUMA 访存开销，对多核高并发场景有明显吞吐提升。关键不在“配了没”，而在“配得准、配得全、配得稳”。
确认硬件与逻辑 CPU 数量
绑定前必须知道系统实际可用的逻辑 CPU 个数，否则掩码位数错、范围超限都会导致启动失败或无效：
- 运行
lscpu | grep "CPU(s):"或nproc查看逻辑 CPU 总数（含超线程） - 检查 BIOS 是否开启超线程（HT），若关闭，则逻辑核数 = 物理核数
- 用
cat /sys/devices/system/cpu/online确认当前启用的核心范围（如0-7表示 8 个逻辑核） - 避免在容器或虚拟机中盲目配置——需确认宿主机透出完整 topology，否则
auto可能误判
选择合适配置写法
推荐优先使用自动模式，兼顾简洁性与健壮性；手动模式适合有 NUMA 意识或需精细控制的场景：
-
推荐写法（Nginx ≥ 1.9.10）：
worker_cpu_affinity auto;，前提是worker_processes已设为auto或明确数值且 ≤ 逻辑核数 - 限制使用前 4 核：
worker_cpu_affinity auto 00001111;（适用于屏蔽超线程或保留核心给其他服务） - 手动指定（以 4 核为例）：
worker_processes 4; worker_cpu_affinity 0001 0010 0100 1000;，每位对应一个逻辑 CPU，最低位（最右）是 core 0 - 注意：不要重复掩码（如
0001 0001），否则多个 worker 会争抢同一核心
配套必须同步调整的参数
单独配置 worker_cpu_affinity 效果有限，需与以下几项协同生效：
- 关闭
accept_mutex（Nginx ≥ 1.11.3 默认已关），防止新连接 accept 锁造成 worker 串行阻塞 - 开启
multi_accept on;，使单个 worker 一次处理多个就绪连接，降低事件循环唤醒频次 - 调高
worker_connections（如65535），并确保系统级ulimit -n和内核fs.file-max匹配 - 将网卡软中断（softirq）也绑定到相同 CPU 核心，例如用
echo 1 > /proc/irq/XX/smp_affinity_list，避免网络包收发与 worker 处理跨核搬运数据
验证是否真正生效
重启 Nginx 后，不能只看配置文件，要从进程运行态交叉验证：
-
ps -eo pid,args,psr | grep 'nginx: worker'→ 查看每个 worker 当前运行在哪颗 CPU（psr列） -
taskset -cp <pid></pid>→ 显示该进程当前实际生效的 CPU 亲和性掩码 -
cat /proc/<pid>/status | grep -E "(Cpus_allowed|Cpus_allowed_list)"</pid>→ 查底层允许范围，比taskset更权威 - 若多个 worker 的
psr值相同，或Cpus_allowed_list重叠，说明配置未生效或核心数不足
