直接绑定CPU核心可显著提升高频静态资源分发性能，核心在于减少跨核缓存失效和上下文切换开销；需先设worker_processes匹配物理核心数，再用worker_cpu_affinity（推荐auto模式）绑定各worker到独占核心，并通过ps、taskset及/proc/pid/status验证生效。
直接绑定 CPU 核心能显著提升高频静态资源分发时的 CPU 处理上限，核心在于减少跨核缓存失效和上下文切换开销。Nginx 默认由内核调度器动态分配 worker 进程到任意 CPU，但在高并发静态服务（如 CDN 边缘节点）场景下，频繁迁移会导致 L1/L2 缓存反复冷启动、TLB 刷新，延迟上升、吞吐下降。启用 worker_cpu_affinity 后，每个 worker 长期驻留固定核心，热点数据（如文件元信息、SSL 会话缓存、共享内存锁）更大概率保留在本地缓存中，指令预取效率也更高。
确认硬件与进程数匹配
绑定前必须确保 worker_processes 数量 ≤ 实际可用逻辑 CPU 数，且优先按物理核分配（尤其在开启超线程的机器上）。操作步骤如下：
- 运行 nproc 或 lscpu | grep "CPU(s)" 查看逻辑 CPU 总数
- 检查 BIOS 是否启用超线程；若开启，8 物理核通常对应 16 逻辑 CPU，但建议只绑物理核（避免两个 worker 争抢同一物理核的执行单元）
- 配置 worker_processes auto（推荐），Nginx 1.9.10+ 会自动识别 NUMA 架构并适配物理核数，比手动写死更稳妥
选择合适绑定方式
不同规模服务器适用不同写法，关键是让每个 worker 独占一个物理核心：
- 双核物理机：使用 worker_cpu_affinity 01 10（第 1 个 worker 绑 core 0，第 2 个绑 core 1）
- 四核物理机：用 worker_cpu_affinity 0001 0010 0100 1000，或更简洁的 worker_cpu_affinity auto
- 八核超线程（16 逻辑 CPU）：若只启 8 个 worker，可写 worker_cpu_affinity auto 0000000011111111 限制只用前 8 个逻辑 CPU，再配合 auto 自动错开超线程对
验证绑定是否真正生效
配置后必须验证，否则可能白忙一场。常用方法：
- 重启 Nginx，执行 ps -eo pid,args,psr | grep 'nginx: worker'，观察各 worker 的 PSR（当前运行 CPU ID）是否互不重复
- 挑一个 PID，运行 taskset -cp
，输出应显示明确绑定的 CPU 列表（如 “pid's current affinity list: 0”） - 检查 /proc/
/status 中的 CPUs_allowed_list 字段，确认掩码值与预期一致 - 若多个 worker 显示相同 PSR 或 CPUs_allowed_list 范围重叠，说明掩码位数错误、core 数不足或配置未加载
配套调优不可少
CPU 绑定只是起点，还需同步调整其他参数才能释放上限：
- 把 worker_connections 提高到 4096 或更高（需同步调大系统级限制：ulimit -n 和 /etc/security/limits.conf）
- 静态资源服务建议开启 sendfile on 和 tcp_nopush on，减少内核态拷贝和小包发送开销
- 若部署在 NUMA 架构服务器上，可结合 numactl --cpunodebind 启动 Nginx，进一步隔离内存访问路径
