要监控每个 worker_processes 的 CPU 负载使用率，需先启用 worker_cpu_affinity 并用 ps 和 taskset 验证进程绑定核心，再通过 pidstat -p <PID> 1 按秒采集 CPU 使用率，结合 access_log 中 $time_local 和 $request_time 对齐分析；若某 worker CPU 长期高 20% 以上，可能未启 accept_mutex 或 reuseport；全 worker 同步波动说明上游瓶颈；单 worker 突升但请求数未增，需查 sendfile、压缩或正则开销；同时用 vmstat 观察 cs 和 si，避免误判调度或软中断问题。
要监控每个 worker_processes 的 CPU 负载使用率，关键不是“看整体 nginx 占用多少 CPU”，而是把 CPU 消耗精确归属到每个 worker 进程，并验证它是否与请求处理行为一致。
确认每个 worker 进程的 PID 和绑定核心
先确保你已启用 worker_cpu_affinity，否则多个 worker 可能被调度到同一核心，数据就失去区分意义。
- 执行
ps aux | grep 'nginx: worker'，记录每个 worker 的 PID - 用
ps -o pid,comm,%cpu,psr -C nginx查看每个 worker 的实时 CPU 占比（%cpu）和运行在哪颗 CPU 上（psr字段） - 再用
taskset -p <PID>验证该进程是否真按配置绑定了指定核心（例如输出pid xxx's current affinity mask: 00000001表示只在 core 0 运行）
按秒采集各 worker 的 CPU 使用率
单次 ps 快照不够，需连续采样对齐请求日志时间线：
- 对每个关键 worker PID 执行：
pidstat -p <PID> 1，每秒输出一次 CPU 使用率，带精确时间戳 - 同时开启 access_log 记录
$time_local和$request_time，确保系统时钟同步（建议启用chronyd） - 将
pidstat输出的时间戳（如06:42:18）与 access_log 中同一秒内该 PID 处理的请求耗时做横向比对
识别不均衡或异常模式
CPU 分布不均往往暴露配置或负载问题：
- 某 worker CPU 长期高于其他 worker 20% 以上 → 可能未启用
accept_mutex on或未配reuseport，导致惊群或连接分配不均 - 所有 worker CPU 波动高度同步 → 压力来自上游（如后端服务慢、DNS 解析卡顿），而非 worker 自身计算瓶颈
- 某个 worker CPU 突然飙升但请求数无明显增加 → 检查是否在处理高开销操作（如大文件 sendfile、高压缩级别、正则重写复杂路径）
辅助验证：结合上下文切换与软中断
单纯看 %cpu 容易误判。需同步观察调度层压力：
- 运行
vmstat 1，关注cs（上下文切换）和in（中断）列：若cs > 30000/秒且 QPS 下降，说明 worker 数过多或锁竞争严重 - 特别注意
si（软中断）：若某核心si接近 100%，说明网络中断处理过载，和 worker CPU 无关，应检查网卡队列、RPS/RFS 或启用reuseport
