验证Nginx进程绑核是否成功需三步：先用ps确认worker进程数与配置一致；再用taskset -cp检查亲和性掩码是否设置正确；最后用top -H观察线程实际运行核心是否稳定在指定CPU上。
验证 Nginx 进程绑核是否成功，不能只看配置写了没、命令执行了没，关键得确认调度行为真实落在指定 CPU 上。以下是生产环境常用、可落地的验证方案，覆盖检查、观察、交叉比对三个层次。
查进程 PID 并确认 worker 数量
先明确当前有多少个 worker 进程在运行，避免漏验：
- 执行 ps -eo pid,comm,args | grep 'nginx: worker'，过滤出全部 worker 进程（注意排除 master）
- 对比 nginx.conf 中 worker_processes 的值，确保实际进程数一致；若配置为 auto，可用 nproc 查物理核心数辅助判断预期数量
- 记录每个 worker 的 PID，后续逐个验证（尤其当使用
worker_cpu_affinity静态绑定时，每个 PID 对应不同核心）
用 taskset -cp 确认亲和性掩码
这是最直接的静态检查，但仅说明“允许运行在哪”，不等于“正在运行在哪”：
- 对任一 worker PID（如 12345），运行 taskset -cp 12345
- 输出类似 pid 12345's current affinity list: 2,5 表示已设置为仅可在 CPU 2 和 5 运行
- 若显示 0-7 或完整范围，说明未生效——检查 nginx 配置是否重载、是否拼写错误（如漏掉分号）、是否在非 root 权限下 reload 导致失败
用 top -H 观察线程级实际运行核心
这才是验证“是否真绑住”的核心步骤，因为 Linux 调度器最终按线程（TID）分配 CPU：
- 执行 top -H -p 12345（12345 是 worker PID）
- 按 f 键进入字段管理 → 找到 P (Last CPU used) → 按空格启用该列
- 持续观察几秒（建议 10 秒以上），所有线程的 P 列值应稳定出现在你指定的核心编号中（如全是 2 或 5）
- 若出现其他核心编号（比如突然跳到 3 或 6），说明绑核未生效或被其他机制干扰（如 cgroups 限制、内核参数干扰）
交叉验证：/proc/PID/status + mpstat 辅助判断
补充两个底层与系统级视角，排除偶然性：
- 查看 /proc/12345/status 中的 Cpus_allowed_list 字段，内容应与
taskset -cp输出一致（如 2,5） - 运行 mpstat -P ALL 1 5（每秒采样一次，共 5 次），观察各 CPU 核心的 %usr 和 %sys：被绑定的核应有明显负载，未绑定的核应基本空闲（尤其在压测期间）
- 若多个 worker 被绑到同一核心却显示负载偏低，可能说明请求未打满，需配合 ab / wrk 做轻量压测再观察
不复杂但容易忽略。重点不是命令会不会敲，而是把“配置—掩码—实际调度—系统负载”这条链路全走通。
