worker_cpu_affinity的核心作用是稳定单worker处理路径、减少跨核缓存抖动与TLB刷新开销，从而提升高负载缓存分发场景下响应一致性与吞吐稳定性，需满足worker_processes>1等前提条件。
在高负载缓存分发场景下，worker_cpu_affinity 的核心作用不是“提升并发数”，而是**稳定单 worker 的处理路径、减少跨核缓存抖动与 TLB 刷新开销**，从而让每个 worker 更高效地服务本地缓存热点（如 proxy_cache、fastcgi_cache）。它本身不扩大处理上限，但能显著提升现有 worker 数下的响应一致性与吞吐稳定性。
明确适用前提：不是所有多核都该绑，更不是越多越快
需先确认三点：
- worker_processes 已设为大于 1（推荐 auto 或明确匹配物理核心数），单进程下该指令无效
- 实际逻辑 CPU 数 ≥ worker 数（用 nproc 或 lscpu | grep "CPU(s)" 验证）
- BIOS 中超线程（HT）状态已知：若关闭，逻辑核 = 物理核；若开启，建议优先绑定物理核而非超线程对（避免争抢执行单元）
缓存分发场景的推荐配置方式
高缓存命中率场景下，worker 长期驻留同一核心更利于 L1/L2 缓存复用。推荐以下写法：
-
通用简洁写法（Nginx ≥ 1.9.10）：
worker_processes auto;
worker_cpu_affinity auto; -
NUMA 架构服务器（如双路 Xeon）：避免跨 NUMA 节点访问内存
例如 2 路 × 6 核（共 12 逻辑 CPU），NUMA node0 含 CPU 0–5，node1 含 6–11
可配：
worker_processes 6;
worker_cpu_affinity 000000111111 000000111111 000000111111 000000111111 000000111111 000000111111;
→ 每个 worker 可在 node0 的 6 核中轮选（掩码全 1），比强制独占更适应 cache warm-up 阶段 -
严格隔离型部署（如混合部署其他服务）：
预留部分核心给系统或后台任务，仅将 Nginx 绑定到专用核
例如 16 核机器，只用前 8 核：
worker_processes 8;
worker_cpu_affinity auto 0000000011111111;
验证是否真正生效的关键命令
重启 Nginx 后，运行以下命令交叉确认：
-
看当前运行核：
ps -eo pid,args,psr | grep 'nginx: worker' | grep -v grep
→ PSR 列应显示分散的 CPU ID（如 0,1,2,3…），而非全部集中于某一个 -
看亲和性掩码：
taskset -cp $(pgrep -f "nginx: worker" | head -1)
→ 应返回类似 “pid xxx’s current affinity list: 0” -
查底层允许范围：
grep -i "cpus_allowed_list" /proc/$(pgrep -f "nginx: worker" | head -1)/status
→ 输出应为单个数字（如 “0”）或小范围连续值（如 “0-3”），非全核（0-11）
配合缓存分发的协同调优项
worker_cpu_affinity 单独启用效果有限，需与以下参数联动：
- proxy_cache_use_stale updating：降低更新缓存时的锁竞争，缓解单核瓶颈
- proxy_buffering on + proxy_buffers：控制 per-worker 内存占用，防止因缓存大对象导致某 worker 内存暴涨而被调度器迁移
- worker_rlimit_nofile 和 ulimit -n 匹配：避免文件描述符耗尽触发 worker 重启，打断 CPU 亲和性
- 禁用非必要模块（如 perl、lua）：减少每个 worker 的静态内存开销，让缓存空间更集中
