必须检查每个 nginx worker 进程的 pid、cpu 使用率和运行核心（psr），用 pidstat 实时采样异常 pid，结合 access.log 中 $request_time 与 $upstream_response_time 定位慢请求根因，并用 taskset 和 mpstat 验证 cpu 绑定效果及负载均衡。
不能只看 top 里“nginx”整体 CPU 占比，必须落到每个 worker 进程，才能真实反映多核调度是否均衡、是否存在单核瓶颈。
查清每个 worker 的 PID 和 CPU 分布
用以下命令列出所有 worker 进程的 PID、CPU 使用率、运行在哪颗 CPU 上（psr 字段）：
ps -o pid,comm,%cpu,psr -C nginx
输出中会看到多个 nginx: worker process 行，每行带一个 PID、当前 CPU 百分比、以及它正在运行的逻辑 CPU 编号（如 psr=2 表示在 core 2）。这一步能快速判断：是否所有 worker 都启动了？有没有某个 worker 持续占满 90%+？有没有多个 worker 被调度到同一颗 CPU 上？
对关键 PID 做秒级 CPU 采样
挑出 CPU 偏高或行为异常的 worker PID（比如上一步看到的 pid=12345），用 pidstat 实时追踪：
-
pidstat -p 12345 1—— 每秒输出一次该进程的 CPU 使用率，含时间戳 - 加
-l可显示完整命令名，确认是 worker 进程而非 master
这个输出能帮你识别短时毛刺（比如某秒飙到 98%）、周期性峰值（每 30 秒规律上涨），或持续高位（连续 10 秒 > 80%），为后续关联日志提供精确时间锚点。
同步采集 Nginx 日志中的响应时间
确保 access.log 中记录了关键时间字段：
-
$request_time：客户端请求总耗时（单位秒，精度毫秒） -
$upstream_response_time：到后端的真实响应耗时 -
$time_local：Nginx 记录日志的时间戳（注意时区是否与系统一致）
例如日志格式可设为：
log_format main '$time_local $request_time $upstream_response_time $status';这样你就能把 pidstat 输出的某一秒（如 14:22:36）和该秒内所有落在 access.log 中的请求日志对齐，进而分析：是不是这个 worker 在那一秒处理了大量慢请求？这些慢请求是卡在 Nginx 自身（$request_time ≫ $upstream_response_time），还是后端拖慢？
交叉验证 CPU 绑定是否生效
如果启用了 worker_cpu_affinity，仅看配置不够，要运行时验证：
- 用
pgrep -f "nginx: worker"获取全部 worker PID - 对每个 PID 执行
taskset -cp <pid></pid>，看输出是否匹配预期（如pid 12345's current affinity list: 0） - 再配合
mpstat -P ALL 1观察各 CPU 核心利用率是否大致均衡
若发现某个 core 长期 95%，其余 core 大部分空闲，说明要么绑核没生效，要么 worker 数量远少于核心数，或者存在锁竞争/惊群效应。
