排查CPU亲和力配置错误需验证worker是否真绑定预期核心及是否存在负载倾斜或缓存失效：先用ps命令检查各核worker分布，再确认worker_cpu_affinity在main块中与worker_processes匹配，配置后nginx -t校验并reload生效，最后用pidstat、perf和nginx_status分析实际负载与缓存表现，并排除accept_mutex、cpusets及内核autogroup干扰。
排查 CPU 亲和力配置错误导致的进程调度不均，关键在于验证 worker 进程是否真正绑定到了预期的 CPU 核心，以及绑定后是否存在负载倾斜或缓存失效现象。这不是看配置写了没，而是看系统实际运行状态。
检查当前 worker 进程的 CPU 分布
运行以下命令，统计每个 CPU 核心上运行的 Nginx worker 数量：
ps -eo pid,ni,pri,pcpu,psr,comm | grep nginx | awk '{++s[$(NF-1)]} END {for (i in s) print "core-id", i, "\t", s[i]}' | sort -nr -k 3若输出显示某几个核心承载了绝大多数 worker（比如 core-id 0 和 2 各有 6 个，其余核心为 0 或 1），说明亲和性未生效或配置与实际核心数不匹配。正常应大致均匀分布（如 8 核机器上 8 个 worker，每核 1 个）。
确认配置语法与生效范围
worker_cpu_affinity 必须放在全局块（main context），且不能与 worker_processes 冲突：
- 若设为 worker_processes 4;，则 worker_cpu_affinity 后必须跟 4 组二进制掩码，如 0001 0010 0100 1000
- 使用 auto 时需确保版本 ≥ 1.9.10，且写法为：worker_processes auto; + worker_cpu_affinity auto;
- 配置后必须执行 nginx -t 验证，再用 nginx -s reload 生效；仅重启 master 不保证 worker 重绑
观察绑定后的实际负载表现
即使进程分布均匀，也不代表调度均衡。需进一步验证：
- 用 pidstat -u -p $(pgrep nginx | head -n1) 1 查单个 worker 的 CPU 使用率，对比多个 worker 是否出现“一高多低”现象
- 检查 perf stat -e cache-misses,cache-references 的 miss ratio，若明显高于 5%，说明跨核调度仍频繁，cache locality 未改善
- 配合 nginx_status 看各 worker 的 Waiting 连接数：若某 worker Waiting 值远高于其他，而 CPU 却不高，可能是它被绑在了 I/O 密集型核心（如同时跑数据库），资源被抢占
排除干扰因素
亲和性效果会被其他配置削弱：
- accept_mutex off; 在高并发下可能放大惊群效应，抵消绑定收益；建议保持默认 on
- 系统启用了 cpusets 或容器限制（如 Docker 的 --cpuset-cpus），会覆盖 Nginx 自身绑定
- 内核参数 kernel.sched_autogroup_enabled = 1 可能干扰进程组调度，生产环境建议设为 0
