调优 worker_cpu_affinity 的核心目标是让每个 Nginx worker 进程长期绑定至同一物理 CPU 核心，避免跨核切换导致的缓存失效、TLB 刷新、分支预测丢失及 NUMA 远端内存访问延迟，从而降低响应抖动；需满足 worker_processes 明确设置、掩码组数匹配进程数、位宽不超逻辑 CPU 总数三大前提，并配合 accept_mutex off、multi_accept on、高连接数及 reuseport 等配置协同生效。
调优 worker_cpu_affinity 的核心目标，就是让每个 Nginx worker 进程长期稳定运行在同一个物理 CPU 核心上，从而避免因 Linux 调度器频繁迁移进程引发的跨核切换开销——这正是响应抖动（latency jitter）的主要来源之一。
为什么跨核切换会引发响应抖动
每次 worker 进程被调度到不同核心时，会触发完整上下文切换：
- L1/L2 缓存内容大量失效，热点数据（如 SSL session cache、共享内存 slab、header 解析缓冲区）需重新加载
- TLB（Translation Lookaside Buffer）被刷新，地址翻译变慢，影响内存访问延迟
- 分支预测器与预取队列状态丢失，指令执行效率下降
- 在 NUMA 架构下，若迁移到远端节点核心，还会引入 2–3 倍内存访问延迟
实测显示：未绑定时，高并发下每秒上下文切换（cs）常超 50 万次，L1 缓存命中率可能从 95% 骤降至 60%，P99 延迟波动明显放大。
正确配置 worker_cpu_affinity 的关键规则
绑定要起效，必须同时满足三个硬性前提：
-
worker_processes 必须设为明确数字（如
4）或auto；仅写auto时，必须搭配worker_cpu_affinity auto - 掩码组数必须严格等于 worker 进程数（4 个 worker 就得写 4 组掩码）
- 每组掩码的二进制位宽不能超过系统实际逻辑 CPU 总数（用
nproc或lscpu | grep "CPU(s)"验证）
推荐写法：按场景选最稳方案
不必手算二进制，优先使用语义清晰、容错强的配置方式：
- 普通多核服务器（Nginx ≥ 1.9.10）：
worker_processes auto;+worker_cpu_affinity auto;—— 自动跳过超线程，按物理核顺序分配 - 只想启用前 N 个物理核（例如屏蔽 HT）：
worker_cpu_affinity auto 00001111;（后缀十六进制掩码限定可用 CPU 集合） - 双路 NUMA 服务器（如 2×8 核）：
worker_processes 8;+worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;—— 每个 worker 独占 socket 0 的一个物理核 - 严格隔离部署（如混跑其他服务）：预留部分核心，例如 16 核机器只用前 8 个逻辑核，写
worker_cpu_affinity auto 0000000011111111;
必须同步关闭干扰项才能释放绑定效果
只配 worker_cpu_affinity 不够，以下几项不调，绑定基本白做：
- 确认
accept_mutex off;已生效（1.11.3+ 默认关闭），否则多个 worker 仍争抢 accept 锁，绑再牢也串行排队 - 开启
multi_accept on;，让单个 worker 一次收多个连接，减少事件循环唤醒频次 - 配高
worker_connections（如10240）并同步提升系统级限制：ulimit -n 65535和fs.file-max = 2097152 - 高并发反代建议启用
reuseport on;，由内核在 socket 层分发连接，彻底绕过用户态锁瓶颈
三步验证是否真正生效
配置 reload 后，必须查运行态，不能只信配置文件：
- 查当前运行在哪颗核：
ps -eo pid,args,psr | grep 'nginx: worker'—— PSR 列应为 0、1、2、3… 且不重复、不跳变 - 查亲和性掩码：
taskset -cp $(pgrep -f "nginx: worker" | head -1)—— 输出应显示类似 “current affinity list: 2”，表示只允许在 CPU 2 运行 - 压测时观察：
mpstat -P ALL 1—— 各核利用率应相对均衡，无某核持续 100%、其余空闲现象
