核心目标是让每个 Nginx worker 独占一个物理核心，杜绝跨核迁移导致的缓存失效、TLB 刷新和 NUMA 远端访存；需先确认物理核心数、禁用超线程干扰、设 worker_processes 为物理核数、按物理核顺序精准配置 worker_cpu_affinity 掩码，并同步关闭 accept_mutex、开启 multi_accept、绑定网卡软中断，最后通过 ps、taskset、mpstat 验证生效。

直接手动绑定 Nginx worker 到指定物理核，核心目标是让每个 worker 独占一个物理核心，从而杜绝进程跨核迁移带来的缓存失效、TLB 刷新和 NUMA 远端内存访问。这不是简单写几个“1”，而是要贴合硬件真实拓扑来操作。

先确认物理核心数，绕开超线程干扰

超线程会让一个物理核暴露为两个逻辑 CPU（如 8 物理核 + HT = 16 逻辑核），但 L1/L2 缓存是共享的。若把两个 worker 绑在同一个物理核的两个逻辑 ID 上，反而会争抢执行单元和缓存带宽。

• 运行 lscpu | grep -E "Core\(s\) per socket|Socket\(s\)"，算出物理核心总数（例如：2 sockets × 6 cores = 12 物理核）
• 再用 nproc 或 lscpu | grep "CPU(s):" 查逻辑核总数（如显示 24，说明 HT 已启用）
• worker_processes 应设为物理核数（如 12），而不是逻辑核数（24）——除非压测明确显示小包低延迟受益于全逻辑核

按物理核顺序写掩码，位序必须严格对齐

每组掩码是一个二进制数，长度等于系统逻辑 CPU 总数，但只在你选定的物理核对应位置置 1。最低位（bit 0）永远对应逻辑 CPU 0，且通常映射到物理核 0 的第一个线程。

• 12 物理核 + HT（24 逻辑核），只用每个物理核的第一个线程（即逻辑 ID 0,2,4…22）：掩码为 010101010101010101010101（24 位，偶数位为 1），再拆成 12 组，每组对应一个 worker
• 更稳妥的做法是用十六进制：8 核可写为 01 02 04 08 10 20 40 80；12 核则用 01 02 04 08 10 20 40 80 0100 0200 0400 0800
• 切忌手算位数出错——位数不匹配、重复绑同一核、跨 NUMA 节点，都会导致配置静默失效

绑定只是起点，必须同步关闭干扰路径

光写 worker_cpu_affinity，不调其他参数，相当于给跑车装了定速巡航却踩着刹车：worker 被绑住了，但还在排队等锁、一次只收一个连接、软中断在隔壁核收包再搬运过来。

• accept_mutex off;：关闭连接接入串行锁（Nginx ≥ 1.11.3 默认已关，旧版本务必显式关）
• multi_accept on;：让每个 worker 一次从内核事件队列取多个就绪连接，减少 epoll 唤醒次数
• 把网卡软中断也绑到相同物理核：查 cat /proc/interrupts | grep eth 找对应 IRQ，再用 echo $MASK > /proc/irq/$IRQ/smp_affinity_list 绑定

验证是否真绑上了，别信配置信数据

配置文件写得再漂亮，不验证等于没做。必须在 Nginx 启动后实测确认：

• ps -eo pid,args,psr | grep 'nginx: worker'：第三列 psr 显示当前运行在哪颗逻辑 CPU 上，应与你设定的掩码一一对应（如 worker 0 → psr=0，worker 1 → psr=2）
• taskset -cp <pid>：输出类似 pid 12345's current affinity list: 0,2,4,6 表示该进程允许运行在逻辑 CPU 0/2/4/6 —— 注意这里要和你的掩码意图一致
• mpstat -P ALL 1：压测时观察各核利用率是否均衡，有没有某核长期 100% 而其他核空闲——那是绑定失败或存在其他瓶颈的信号