（案例6）如何迅速分析出系统 CPU 的瓶颈

前言

• 在做性能测试时，我们会需要对 Linux 系统的性能指标进行分析
• 这一篇就来讲下 CPU 性能指标的一个整体分析思路流程
• 总结出一个“又快又准”的瓶颈定位套路，在不同场景下，指标工具怎么选，性能瓶颈怎么找

CPU 性能指标

一共有四个需要掌握了解的性能指标

CPU 使用率

再次总结

• 最常见的一个性能指标
• 描述了非空闲时间占总 CPU 时间的百分比
• 根据 CPU 上运行任务的不同，又被分为：用户 CPU、系统 CPU、等待 I/O CPU、软中断、硬中断

用户 CPU 使用率

• 表示 CPU 在用户态运行的时间百分比
• 包括：用户态的 CPU 使用率（user）和低优先级的用户态 CPU 使用率（nice） 
• 用户 CPU 使用率高，说明有应用程序比较繁忙

系统 CPU 使用率

• 表示 CPU 在内核态运行的时间百分比（不包括中断）
• 系统 CPU 使用率高，说明内核比较繁忙

等待 I/O 的 CPU 使用率

• 通常也称为 iowait，表示等待 I/O 的时间百分比
• iowait 高，通常说明系统与硬件设备的 I/O 交互时间比较长

软中断和硬中断的 CPU 使用率

• 分别表示内核调用软中断处理程序、硬中断处理程序的时间百分比
• 它们的使用率高，通常说明系统发生了大量的中断

虚拟化环境

• 窃取 CPU 使用率（steal）：被其他虚拟机占用的 CPU 时间百分比
• 客户 CPU 使 用率（guest）：运行客户虚拟机的 CPU 时间百分比

平均负载

平均活跃进程数

理想情况

• 平均负载等于逻辑 CPU 个数，这表示每个 CPU 都恰好被充分利用
• 如果平均负载大于逻辑 CPU 个数，就表示负载比较重了

进程上下文切换

两种类型

• 自愿上下文切换：无法获取资源而导致
• 非自愿上下文切换：被系统强制调度而导致

重点知识

• CPU 上下文切换本身是保证 Linux 正常运行的一项核心功能
• 过多的上下文切换，会将运行进程的 CPU 时间，消耗在寄存器、内核栈、虚拟内存等数据的保存和恢复上
• 最终，缩短进程真正运行的时间，成为性能瓶颈

CPU 缓存命中率

为什么会有缓存命中率

• 由于 CPU 发展的速度远快于内存的发展，CPU 的处理速度就比内存的访问速度快得多
• 这样，CPU 在访问内存的时候，免不了要等待内存的响应
• 为了协调这两者巨大的性能差距，CPU 缓存（通常是多级缓存）就出现了

• 就像上面这张图显示的，CPU 缓存的速度介于 CPU 和内存之间，缓存的是热点的内存数据
• 根据不断增长的热点数据，这些缓存按照大小不同分为 L1、L2、L3 等三级缓存，其中 L1 和 L2 常用在单核中， L3 则用在多核中
• 从 L1 到 L3，三级缓存的大小依次增大，相应的，性能依次降低（当然比内存还是好得 多）
• 而它们的命中率，衡量的是 CPU 缓存的复用情况，命中率越高，则表示性能越好

CPU 性能工具

重点

把性能指标和性能工具联系起来，下面个将从两个维度来讲这个点

第一个维度：从 CPU 的性能指标出发

• 也就是说，当你要查看某个性能指标时，要清楚知道哪些工具可以做到
• 总结：哪个工具可以查看哪些指标

第二个维度：从工具触发

要明确知道这个工具能提供哪些指标

重点！重点！重点！来了！

如何快速分析 CPU 的性能瓶颈

在实际生产环境中，我们通常都希望尽可能快地定位系统的瓶颈，然后尽可能快地优化性能，也就是要又快又准地解决性能问题

认知

• 虽然 CPU 的性能指标比较多，但要知道，既然都是描述系统的 CPU 性能，它们就不会是完全孤立的，很多指标间都有一定的关联
• 想弄清楚性能指标的关联性，就要通晓每种性能指标的工作原理

实例：

• 用户 CPU 使用率（us）高，应该去排查进程的用户态而不是内核态，因为用户 CPU 使用率反映的就是用户态的 CPU 使用情况
• 而内核态的 CPU 使用情况只会反映到系统 CPU 使用率（sy）上

CPU 使用率高的场景，如何进行一系列的性能分析

列出了 top、vmstat 和 pidstat 分别提供的重要的 CPU 指标，并用虚线表示关联关系，对应出了性能分析下一步的方向

下面举些小栗子

例如：

1. top 看到用户态 CPU 使用率偏高
2. 可以根据 pidstat 的输出进一步观察是否是某个进程导致的问题
3. 找出 CPU 使用率偏高的进程之后就要用进程分析工具来分析进程的行为
4. 比如使用 strace 分析系统调用情况，perf 分析调用链中各级函数的执行情况

例如：

1. top 看到平均负载升高
2. 通过 vmstat 查看 R 状态和 B 状态的进程数，是否有数量上的异常
3. 如果不可中断状态的进程数过多，需要做 I/O 的分析，可以通过 dstat 或 sar 工具来分析 I/O
4. 如果是运行状态的进程数过多，可以通过 pidstat 确认处于运行状态的进程，然后用进程分析工具做进一步分析

例如：

1. top 看到软中断 CPU 使用率（si）偏高，进程列表能看到软中断进程 CPU 使用率也偏高
2. 可以根据读取 /proc/softirqs 查看软中断类型和变化频率
3. 如果是网络相关软中断导致的问题，可以进一步通过网络分析工具 sar、tcpdump 来分析