“CPU 90%”只说明观测区间内大部分时间没有运行空闲线程，并没有说明请求是否在排队、哪个代码路径消耗周期，甚至没有说明处理器是否高效执行指令。内存停滞、单核热点、容器配额、硬中断、虚拟化偷取时间，都可能在相似的总使用率下产生不同的业务表现。

本章给出三层视角：先看容量与调度，判断是否真的缺 CPU；再用剖析找到消耗 CPU 的代码路径；最后用周期、指令、缓存和分支等硬件计数解释为什么该路径效率低。

1. 总平均会掩盖热点。 必须同时查看每个逻辑 CPU、线程和中断分布，单线程跑满时整机平均仍可能很低。
2. 使用率不等于有效计算。 CPU 被计为忙碌时，可能正在等待内存；IPC、缓存未命中和停滞周期用于解释效率。
3. 饱和要看等待。 运行队列长度、调度器延时与 CPU PSI 比“接近 100%”更直接地反映线程拿不到 CPU。
4. 先剖析，再谈微架构。 先找到宽代码路径，避免在占比很小的函数上优化缓存或分支。
5. 拓扑和边界会改变结论。 SMT 线程不等于完整物理核；NUMA、亲和性、配额、降频和虚拟化偷取都要纳入分析。

可运行线程 → [每 CPU 运行队列] → 逻辑 CPU → 指令流水线
                 调度延时          ├─ 有效执行周期
                                    └─ 内存/缓存/分支等停滞周期

• 每 CPU 使用率：重点区分 %usr、%sys、%irq、%soft、%steal 与 %idle。整体值不能替代单 CPU 值。
• 运行队列与调度器延时：等待运行的线程数及从可运行到真正上 CPU 的时间，是 CPU 饱和度指标。
• 平均负载：Linux 中近似表示正在运行、可运行及部分不可中断睡眠任务的需求；1、5、15 分钟值为指数衰减均值，且通常未按 CPU 数归一化。
• CPU PSI：报告任务因 CPU 资源不足而停滞的时间比例，常见窗口为 10、60、300 秒；它更直接回答“任务多大概率要等 CPU”。
• IPC/CPI：每周期指令数及其倒数。低 IPC 常提示内存停滞等问题，但高 IPC 也可能来自一个无用的寄存器循环，必须与完成的业务工作结合。
• 频率与周期：动态调频、热节流和睿频会改变每秒可用周期；“同样 80%”在不同频率下并非同等算力。

1. 记录 CPU 插槽、核、SMT 线程、NUMA、当前配额/亲和性与虚拟化环境，明确可用容量。
2. 看 uptime 判断需求趋势，但立刻用 vmstat、mpstat 和 PSI 区分 CPU、I/O/不可中断任务及局部热点。
3. 用 USE：逐 CPU 检查使用率、运行队列/调度延时和硬件错误；容器还要检查 CPU 配额与节流。
4. 用 pidstat、线程视图和中断统计找主要消费者，区分用户、内核、软/硬中断与 steal 时间。
5. 对目标进程或全系统做短时栈采样，先研究火焰图最宽的塔及其上层调用者。
6. 若主要路径仍不够快，使用 perf stat/PMC 查看周期、指令、IPC、缓存和分支；按处理器文档解释事件。
7. 对间歇抖动，用调度延时直方图或亚秒级剖析选择故障窗口，避免把 100 ms 事件稀释在 30 秒均值中。
8. 优化后以相同工作负载复验吞吐量、延时、CPU 秒/请求与成本，不只比较 CPU 百分比。

uptime
cat /proc/pressure/cpu
vmstat 1 5
mpstat -P ALL 1 5
pidstat -u 1 5
ps -eLo pid,tid,psr,stat,pcpu,comm
perf stat -a -- sleep 5
perf record -F 99 -a -g -- sleep 10
perf report --stdio
runqlat 10 1
runqlen 10 1

前六项主要读取计数器。perf 是否能访问硬件事件受 perf_event_paranoid、容器权限、虚拟化和处理器型号影响；缺少事件不等于硬件没有该行为。runqlat、runqlen 通常来自 BCC/BPF，事件繁忙系统中 runqlat 跟踪调度事件可能有明显开销，宜先用采样型 runqlen 或在测试环境评估。命令参数随版本变化，以本机帮助为准。

• uptime 的 1 分钟值高于 15 分钟值表示需求近期上升，但负载值应结合 CPU 数和 D 状态任务；不要据此单独扩容 CPU。
• vmstat r 在 Linux 中通常包含正在运行和可运行任务。持续高于可用逻辑 CPU 数只是饱和线索，SMT、配额和任务长度会影响实际延时。
• mpstat 若只有一个 CPU 的 %idle 接近零，优先查单线程、亲和性或中断绑定；所有 CPU 忙且 PSI/调度延时升高才像全局不足。
• %sys 高可能来自系统调用、内核线程或中断；用进程 CPU、/proc/interrupts、/proc/softirqs 和剖析继续分解。
• %iowait 表示 CPU 空闲时存在未完成 I/O 的一种记账状态，不是磁盘服务时间，也不能代表某进程等待比例。
• 火焰图 X 轴不是时间，宽度是采样占比；若只在短时窗口异常，应单独截取该窗口再生成火焰图。
• perf stat 的 IPC 只能在同硬件、相似工作负载与采样范围下解释。先确认事件是否被复用、虚拟化或不受支持。

1. CPU 使用率高就扩容。 若主要时间是无用循环、锁自旋或内存停滞，扩容可能只放大浪费。
2. 整机 25% 就认为有 75% 余量。 四核机器上的单线程可已达到自身上限。
3. 平均负载除以 CPU 数就得到使用率。 负载包含排队和部分不可中断任务，概念不同。
4. 把 SMT 线程当独立物理核。 同核硬件线程共享执行资源，收益依工作负载而变。
5. IPC 越高代码越好。 IPC 描述周期利用，不描述完成的是不是有价值的业务指令。
6. 为修性能直接绑定 CPU 或改调度优先级。 这些是有系统级副作用的调优动作，应在证据、隔离测试和回滚方案齐备后进行。

1. 为什么 32 核机器整体 CPU 仅 4% 时，单线程接口仍可能 CPU 饱和？
2. 运行队列长度、调度延时和 CPU PSI 各自表达什么？
3. 高使用率、低 IPC 常提示什么方向？为什么不能直接下结论？
4. %iowait 为什么不能当作磁盘延时？
5. CPU 火焰图和亚秒级窗口分析分别适合发现哪类问题？

CPU 分析要从“忙不忙”推进到“谁在等、谁在跑、周期做了什么”。每 CPU 使用率、运行队列和 PSI 判断容量与调度；线程、进程和中断统计定位消费者；火焰图解释代码路径；PMC/IPC 再解释微架构效率。所有结果都应结合拓扑、频率、配额、虚拟化和业务完成量，才能形成可执行结论。