要确认Nginx worker进程是否真正绑定CPU核心并负载均衡，需用taskset -cp查各worker实际绑定核、mpstat -P ALL观察各核利用率，结合cs、cache-misses等指标交叉验证，再脚本化巡检绑核生效数与负载标准差。
要确认 Nginx 工作进程是否真正按 worker_cpu_affinity 配置绑定了 CPU 核心，并验证各核心负载是否均匀，不能只看配置文件是否写对——得用系统级工具实测运行时状态。
查进程实际绑定的 CPU 核心
使用 taskset -cp 查看单个 worker 进程当前绑定的 CPU 列表：
- 先获取所有 Nginx worker 进程 PID：
ps -eo pid,comm,args | grep 'nginx: worker' | awk '{print $1}' - 对每个 PID 执行：
taskset -cp 12345（12345 替换为实际 PID） - 输出类似
pid 12345's current affinity list: 0表示该进程只在 CPU 0 上运行
若输出显示 0-3 或 all，说明亲和性未生效，需检查配置是否重载、Nginx 是否以非 root 权限启动（部分内核限制非特权进程修改亲和性）。
实时观察各 CPU 核心利用率分布
用 mpstat -P ALL 1 每秒刷新一次，观察每颗核心的 %usr 和 %sys：
- 理想状态：每个 worker 绑定一个核心时，对应核心利用率应明显高于其他核心，且各绑定核心间负载接近（如都在 60%–85%，无长期 100% 或低于 20%）
- 异常信号：
CPU0长期 95%+ 而CPU1–CPU3多数时间低于 10%，说明绑核失败或某 worker 承载了远超均值的流量（比如 upstream 不均、geoip 路由倾斜）
注意：top 默认不按核心分组，需按 1 键展开所有 CPU，再按 P（大写）按 CPU 使用率排序，辅助定位热点核心。
结合上下文切换与缓存指标交叉验证
仅看 CPU 利用率不够——绑核的核心价值在于降低调度开销与提升缓存命中。可同步采集以下指标：
-
vmstat 1中的cs（context switch）字段：稳定服务下建议控制在每秒 ≤ 5 万次；若 >10 万次，即使绑核也可能是 worker 进程数过多或存在锁竞争 -
perf stat -e cycles,instructions,cache-misses -p：对比不同 worker 的sleep 10 cache-misses/cycle比值，绑核后该值应明显低于未绑核时（下降 30%+ 较常见） -
cat /proc/：确认内核层面已应用掩码，例如输出/status | grep -i "cpus_allowed" Cpus_allowed: 00000001对应 CPU 0
自动化巡检建议
把关键检查点脚本化，便于日常巡检或告警：
- 检查绑核是否全部生效：
ps -eo pid,comm | grep 'nginx: worker' | awk '{print $1}' | xargs -I{} taskset -cp {} 2>/dev/null | grep -v "no such process" | wc -l应等于worker_processes数量 - 检查负载均衡度：用
mpstat -P ALL 1 3 | tail -n +4 | awk '$3 ~ /^[0-9.]+$/ {sum[$2]+=$3; cnt[$2]++} END {for (c in sum) print c, sum[c]/cnt[c]}'计算各核平均用户态使用率，标准差超过 25% 即提示不均
不复杂但容易忽略的是：绑核只是起点，后续还需配合连接数、文件描述符、上游健康检查等一并调优，才能让每个核心真正“稳而高效”地跑起来。
