直接用 worker_cpu_affinity auto 最稳妥高效，它自动绑定每个 worker 到独立物理核，避免超线程争抢、缓存失效和 numa 远端访存；需配合设 worker_processes 为物理核数、关 accept_mutex、开 multi_accept，并将网卡软中断绑至相同物理核。
直接用 worker_cpu_affinity auto 就行，这是最稳妥、见效最快的方式。它自动识别物理核心数，跳过超线程逻辑核，让每个 worker 独占一个真实物理核，从根源上消除跨核迁移带来的缓存失效、TLB 刷新和 NUMA 远端访存问题。
先确认硬件真实拓扑，别被超线程带偏
超线程会让一个物理核暴露成两个逻辑 CPU（比如 8 物理核 + HT = 16 逻辑核），但 L1/L2 缓存和执行单元是共享的。若把两个 worker 绑在同一个物理核的两个逻辑 ID 上，反而会争资源。
- 运行 lscpu | grep -E "Core\(s\) per socket|Socket\(s\)"，算出物理核心总数（如 2 sockets × 8 cores = 16）
- 再用 nproc 或 lscpu | grep "CPU(s):" 查逻辑核总数（如显示 32，说明 HT 已启用）
- worker_processes 应设为物理核数（如 16），而不是逻辑核数（32）——除非压测明确证明小包低延迟受益于全逻辑核
用 auto 模式起步，省错又适配
Nginx ≥ 1.9.10 支持 auto 模式，它比手动写掩码更健壮，尤其适合云环境或 NUMA 架构。
- worker_cpu_affinity auto; —— 自动为每个物理核分配一个 worker，L1/L2 缓存局部性最优
- worker_cpu_affinity auto 00001111; —— 后缀十六进制掩码，限制只使用前 4 个逻辑 CPU（对应前 2 或 4 物理核），适合容器限频场景
- 不建议混用：比如 worker_processes 8 却只给 4 组掩码，剩余 worker 会 fallback 到默认调度
绑定只是起点，必须同步关掉干扰项
光写 worker_cpu_affinity 不调其他参数，等于绑住车轮却踩着刹车——worker 被固定了，但还在排队等锁、一次只收一个连接、软中断在隔壁核收包再搬运过来。
- accept_mutex off; —— 关闭连接接入串行锁（Nginx ≥ 1.11.3 默认已关，旧版本务必显式关）
- multi_accept on; —— 让每个 worker 一次从内核事件队列取多个就绪连接，减少 epoll 唤醒次数
- 把网卡软中断也绑到相同物理核：查 cat /proc/interrupts | grep eth0 找对应 IRQ，再用 echo $MASK > /proc/irq/$IRQ/smp_affinity 绑定
三步验证是否真绑上了
别只看配置文件，运行后必须实测确认：
- 查各 worker 当前在哪颗核运行：ps -eo pid,args,psr | grep 'nginx: worker' —— 第三列 psr 应为互不重复的数字（如 0、1、2、3），且不超过你设定的物理核范围
- 查某进程允许跑的 CPU 列表：taskset -cp
—— 输出类似 pid 12345's current affinity list: 2 表示只允许在 CPU 2 运行 - 压测时观察：mpstat -P ALL 1 —— 各核利用率应相对均衡，没有某核长期 100% 而其他核空闲的情况
