worker_cpu_affinity本身不提升吞吐，关键在于让每个Nginx worker独占逻辑CPU核心以避免跨核调度开销；需确认真实逻辑核数、合理选择绑定方式、同步调优accept_mutex等参数，并通过ps/taskset/proc验证生效。
直接配置 worker_cpu_affinity 本身不提升吞吐，关键在于让每个 Nginx worker 独占一个逻辑 CPU 核心，避免跨核调度引发的缓存失效、TLB 刷新和 NUMA 跨节点访存——这在负载均衡场景下尤其重要，因为 upstream 请求分发、SSL 握手、连接复用等操作对 CPU 缓存敏感。
确认真实可用的逻辑 CPU 数量
负载均衡节点通常高并发、低延迟要求严，错配掩码会导致启动失败或绑定无效：
- 运行
nproc或lscpu | grep "CPU(s):"查逻辑核总数（含超线程） - 检查
cat /sys/devices/system/cpu/online，确认系统启用的核心范围（如0-7表示 8 个逻辑核） - BIOS 中若关闭超线程，则逻辑核数 = 物理核数；开启则通常翻倍
- 容器或虚拟机中需确认宿主机透出完整 CPU topology，否则
auto可能误判核心数量
选择适配负载均衡场景的绑定方式
负载均衡流量模型偏重连接建立与转发，建议优先使用自动模式并限制范围，避免把 worker 绑到被网卡软中断或监控进程占用的核心上：
- 推荐写法：
worker_processes auto;+worker_cpu_affinity auto;（Nginx ≥ 1.9.10） - 若需保留前 2 核给网卡 softirq 或其他服务，写：
worker_cpu_affinity auto 00001111;（仅用后 4 核） - 手动指定（以 8 核为例）：
worker_processes 8; worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000; - 切勿重复掩码（如
0001 0001），否则多个 worker 争抢同一核心，反而加剧锁竞争
必须同步调整的配套参数
只配 worker_cpu_affinity 效果有限，负载均衡场景还需以下协同：
- 确保
accept_mutex off;（Nginx ≥ 1.11.3 默认已关），防止新连接 accept 锁导致 worker 串行阻塞 - 开启
multi_accept on;，使单个 worker 一次处理多个就绪连接，降低事件循环唤醒频次 -
worker_connections设为较高值（如65535），并同步调大系统级ulimit -n和内核fs.file-max - 将网卡 softirq 绑定到与对应 worker 相同的 CPU 核心，例如：
echo 1 > /proc/irq/XX/smp_affinity_list，避免网络包收发与请求处理跨核搬运数据
验证是否真正生效
重启 Nginx 后，不能只看配置文件，要从运行态交叉验证：
-
ps -eo pid,args,psr | grep 'nginx: worker'→ 查看每个 worker 当前运行在哪颗 CPU（psr列） -
taskset -cp→ 显示该进程当前实际生效的 CPU 亲和性掩码 -
cat /proc/→ 查底层允许范围/status | grep -E "(Cpus_allowed|Cpus_allowed_list)" - 若多个 worker 显示相同
psr值或Cpus_allowed_list重叠，说明配置未生效或核心数不足
