调优 worker_cpu_affinity 的关键是让每个 worker 稳定绑定匹配的物理核心，减少缓存抖动、tlb 刷新和跨 numa 访存开销；需先识别真实物理拓扑，优先绑定不同物理核、按 numa 分组，用 auto 模式起步并严格验证绑定效果。
调优 worker_cpu_affinity 对高规格服务器（如 16 核以上、NUMA 架构、超线程开启）提升处理性能，关键不是“多绑几个核”，而是让每个 worker 稳定驻留最匹配的物理核心，减少缓存抖动、TLB 刷新和跨节点内存访问开销。它不增加并发能力上限，但能让已有的 worker 更高效地服务缓存热点、SSL 加解密、静态文件分发等 CPU 密集型任务。
先确认硬件真实拓扑，避开超线程陷阱
高规格服务器常启用超线程（HT），lscpu 显示的逻辑核数可能是物理核的两倍。但两个逻辑核共享同一物理核的 L1/L2 缓存和执行单元。盲目按 32 个逻辑核配 32 个 worker 并全绑定，反而引发争抢。
- 运行
lscpu | grep -E "(CPU\(s\)|Core|Socket|Thread)"，算出真实物理核数 = Core(s) per socket × Socket(s) - 若 Thread(s) per core = 2（即 HT 开启），优先绑定到不同物理核，而非所有逻辑核
- BIOS 中临时关闭 HT 测试吞吐稳定性——尤其在 TLS 终结或 upstream 延迟高时，关闭后延迟更稳
按 NUMA 架构分组绑定，避免跨节点访存
双路/四路 Xeon 或 EPYC 服务器普遍存在 NUMA 拓扑。跨 NUMA 节点访问内存延迟高、带宽低，会抵消 CPU 绑定收益。
- 用
numactl --hardware查看节点分布，例如 node0 含 CPU 0–15，node1 含 16–31 - 若部署为独立网关或 CDN 边缘节点，推荐按节点划分 worker：设
worker_processes 16，再配worker_cpu_affinity 00000000000000001111111111111111 00000000000000001111111111111111 ...（共 16 组），让每个 worker 在 node0 的 16 核中轮选，比强制独占更适应 warm-up 阶段 - 若需严格隔离（如混部数据库），可限定只用 node0 的前 8 核：
worker_cpu_affinity auto 00000000000000001111111100000000
用 auto 模式起步，再按需收紧范围
手动写长串二进制掩码极易出错，且难适配云环境（vCPU 数虚高但物理资源受限）。Nginx ≥ 1.9.10 的 auto 是更健壮的起点。
-
worker_cpu_affinity auto;：自动跳过超线程对称核，每个 worker 独占一个物理核，L1/L2 缓存局部性最优 -
worker_cpu_affinity auto 00001111;：后缀十六进制掩码限定可用 CPU 集合，适合容器中限制 vCPU 配额 - 不建议混用：比如
worker_processes 16却只提供 8 组掩码，剩余 worker 会 fallback 到内核默认调度，失去控制意义
验证必须做，否则等于没配
配置 reload 后不能只信日志，要实打实查进程状态：
-
ps -eo pid,args,psr | grep 'nginx: worker'：每个 PID 对应的 PSR 列应是不同数字（如 0、2、4、6…），且不重复；若多个 worker 显示相同 PSR，说明配置未生效或核心数不足 -
taskset -cp $(pgrep -f "nginx: worker" | head -1)：输出应显示明确绑定的 CPU 列表（如 “pid 12345's current affinity list: 0”） -
cat /proc/$(pgrep -f "nginx: worker" | head -1)/status | grep Cpus_allowed_list：确认掩码值与预期一致（如 “Cpus_allowed_list: 0-1”）
