手动配置worker_cpu_affinity的核心目标是让每个Nginx worker进程独占一个物理CPU核心，避免跨核缓存失效、TLB刷新和NUMA跨节点内存访问；需匹配逻辑核数与worker数量，禁用重复掩码，并配合accept_mutex off、multi_accept on及软中断绑定等措施协同优化。

手动配置 worker_cpu_affinity 的核心目标，是让每个 Nginx worker 进程独占一个物理 CPU 核心，避免跨核缓存失效、TLB 刷新和 NUMA 跨节点内存访问。这不是“配了就快”，而是要精准对齐硬件拓扑与进程数量，再配合关键调度策略才能压出静态吞吐上限。

确认硬件逻辑核数与 worker 数量匹配

先用 lscpu | grep "CPU(s)" 查清逻辑 CPU 总数（含超线程）。worker_processes 必须 ≤ 该数值，且建议设为等于物理核心数（非超线程数），尤其在高吞吐场景下：

• 4 物理核 + 超线程 → 8 逻辑核，但优先设 worker_processes 4，绑定到 4 个物理核
• 若确需启用全部逻辑核（如低延迟小包场景），则必须确保 worker_cpu_affinity 掩码位数与逻辑核总数一致
• 虚拟机中需确认宿主机透出完整 topology，否则 lscpu 显示可能失真

按位顺序写二进制掩码，严格一一对应

每组掩码是一个二进制数，长度 = 逻辑 CPU 总数，最低位（最右）代表 core 0。各组顺序对应 worker 进程启动顺序（从 master fork 出的第 1 个、第 2 个……）：

• 双核（2 逻辑核）：worker_processes 2; → worker_cpu_affinity 01 10;
• 四核（4 逻辑核）：worker_processes 4; → worker_cpu_affinity 0001 0010 0100 1000;
• 八核（8 逻辑核）：worker_processes 8; → worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
• 禁止重复掩码（如 0001 0001），否则多个 worker 会争抢同一核心

关闭 accept_mutex 并开启 multi_accept

仅绑核不够，还要消除 worker 间串行瓶颈：

• accept_mutex off; —— Nginx ≥ 1.11.3 默认已关，旧版本务必显式关闭，防止 accept 锁阻塞
• multi_accept on; —— 让单个 worker 一次处理多个就绪连接，降低 epoll 唤醒频率
• 二者配合，才能让每个绑定核心真正“吃饱”，避免空转等待

验证是否真正生效

重启 Nginx 后，不能只看配置文件，要查实际运行态：

• 查 worker 进程 PID 和当前运行核：ps -eo pid,args,psr | grep 'nginx: worker'
• 查某 worker 的亲和掩码：taskset -cp <pid></pid>，输出应显示唯一 CPU ID
• 查底层允许列表：grep -i "cpus_allowed_list" /proc/<pid>/status</pid>，确认值为单个数字（如 0）
• 若多个 worker 显示相同 psr 或 CPUs_allowed_list 包含多核，说明配置错误或核心数不足