3. CPU性能分析与容量评估

CPU 是 RHEL 系统上最容易被“感觉慢”背锅的部件，但真正定位瓶颈时，不能只看 top 里那个百分比。CPU 性能分析要回答三个层次的问题：CPU 到底忙在用户态、内核态还是等待 I/O；上下文切换和运行队列是否异常；以及当前负载下需要多少 vCPU 才能把压力降到可接受范围。本节围绕 top、mpstat、pidstat、perf 四个工具，给出从观察到估算的完整路径。

一、先分清 CPU 时间的去向

在 RHEL 中，top 顶部一行给出 us（用户态）、sy（内核态）、ni（调整过优先级的用户态）、id（空闲）、wa（等待 I/O）、hi（硬中断）、si（软中断）、st（被虚拟化层偷走的时间）等字段。判断瓶颈时，先看 id 是否长期低于 20%，再看 wa 是否偏高。如果 wa 高而 us 不高，问题往往在磁盘或网络 I/O，而不是 CPU 算力不足；如果 st 明显，说明宿主机超卖，需要从虚拟化层排查。

mpstat -P ALL 1 比 top 更适合看多核分布。它按 CPU 逐行输出，能暴露“单核跑满、其他核空闲”的情况。例如某台 8 vCPU 的 Web 服务器，mpstat 显示 CPU0 的 %usr 长期在 95% 以上，而 CPU1~7 只有 10% 左右，这说明应用存在单线程热点或中断集中，盲目加 vCPU 并不能解决问题，应先做中断亲和性或应用线程模型优化。

二、上下文切换与运行队列

上下文切换分为自愿切换（cswch/s）和非自愿切换（nvcswch/s）。自愿切换多，通常意味着进程在等 I/O 或锁；非自愿切换多，说明进程被时间片强制剥夺 CPU，往往伴随运行队列变长。pidstat -w 1 可以按进程查看这两个指标，pidstat -u 1 则给出每个进程的 %usr、%system、%CPU。

运行队列长度用 vmstat 1 的 r 列观察。经验上，r 持续大于逻辑 CPU 数的 1~2 倍，就说明 CPU 已经排队。例如 4 vCPU 的机器 r 长期在 8~12，说明平均有 2~3 倍的可运行任务在等 CPU，此时扩容或限流才有意义。

三、用 perf 定位热点函数

当确认 CPU 确实忙在用户态或内核态后，用 perf top 或 perf record 找热点。下面是一段示例命令，用于采集 10 秒的 CPU 周期事件并生成报告：

perf record -F 99 -a -g -- sleep 10
perf report --stdio | head -40

输出中会按符号聚合，显示哪个函数、哪个库占用最多采样。若热点集中在某个业务函数，属于应用优化；若集中在 spin_lock、memcpy、schedule 等内核符号，则要检查锁竞争、内存拷贝或调度压力。注意 perf 采样是统计性的，样本量足够时结论才可靠。

四、估算所需 vCPU 数量

容量估算不能只看“当前 CPU 使用率”，而要把峰值、增长和冗余一起考虑。一个可操作的估算方法是：先取业务高峰期的平均 CPU 使用率，再乘以峰值系数，最后除以单核可承受的目标利用率。公式可写为：

所需 vCPU = 高峰平均使用率 × 峰值系数 ÷ 目标单核利用率

假设某应用在 8 vCPU 上高峰平均使用率为 55%，峰值系数取 1.5，目标单核利用率取 70%，则所需 vCPU ≈ 0.55 × 8 × 1.5 ÷ 0.70 ≈ 9.4，向上取整为 10 vCPU。如果当前运行队列 r 已经持续超过 CPU 数，说明这个估算还应再留一档余量。反之，如果 wa 高而 us 低，加 vCPU 不会改善响应时间，应先解决 I/O。

五、把观察串成判断链

下面这张图把本节的关键判断关系集中呈现：从 top 的总览出发，分流到 mpstat 的核间分布、pidstat 的进程级切换、perf 的热点函数，最终落到“加 vCPU、优化应用、还是先处理 I/O”的决策上。

把这条链走完，CPU 容量评估就不再是“看百分比拍脑袋”。实际工作中建议固定一个采样窗口，例如连续采集 5 分钟，记录 mpstat 的 %usr、%sys、%wa、%idle，vmstat 的 r 和 cs，以及 pidstat 中排名前几的进程。把这些数据与业务高峰时间对齐，再套用上面的估算公式，得到的 vCPU 数量才有依据。最后提醒一点：扩容后要复测同一组指标，确认运行队列下降、%idle 回升，否则说明瓶颈并不在 CPU 数量上。