在高负载缓存分发场景中，如何设置worker_cpu_affinity以优化多核处理能力？

本文共计835个文字，预计阅读时间需要4分钟。

在负载均衡的缓存分发展景下，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 的静态内存开销，让缓存空间更集中