【linux性能优化】分析系统CPU瓶颈

CPU 的性能指标那么多，CPU性能分析工具一大把，在实际的工作场景该观察什么指标、选择哪个性能工具呢？

接下来分析在不同场景下，指标工具怎么选，性能瓶颈怎么找

一、CPU 性能指标

回顾下，描述CPU的性能指标都有哪些

1.1 CPU使用率

首先，最容易想到的应该是CPU使用率，这也是实际环境中最常见的一个性能指标

CPU使用率描述非空闲时间占总CPU时间的百分比，根据CPU上运行任务的不同，被分为用户CPU、系统CPU、等待I/O CPU、软中断和硬中断等

• 用户CPU使用率

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

• 系统CPU使用率

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

• 等待I/O CPU使用率

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

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

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

除了这些，还有在虚拟化环境中会用到的窃取CPU使用率(steal)和客户CPU使用率(guest)，分别表示被其他虚拟机占用的CPU时间百分比，和运行客户虚拟机的CPU时间百分比

1.2 平均负载

第二个比较容易想到的，应该是平均负载(Load Average)，也就是系统的平均活跃进程数

反应系统的整体负载情况，主要包括三个数值，分别指过去1分钟、过去5分钟和过去15分钟的平均负载

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

1.3 进程上下文切换

第三个是不太会注意到的进程上下文切换，包括：

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

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

1.4 CPU缓存命中率

除了上面几种，还有一个指标，CPU缓存的命中率

由于CPU的处理速度比内存的访问速度快得多，CPU在访问内存的时候，免不了要等待内存的响应，需要使用CPU缓存(通常是多级缓存)协调这两者巨大的性能差距

如上面这张图，CPU缓存的速度介于CPU和内存之间，缓存的是热点的内存数据
根据不断增长的热点数据，这些缓存按照大小不同分为L1、L2、L3等三级缓存，其中L1和L2常用在单核中，L3则用在多核中

从L1到L3，三级缓存的大小依次增大，相应的性能依次降低(当然比内存还是好得多)，而它们的命中率，衡量的是CPU缓存的复用情况，命中率越高，则表示性能越好

根据上面的性能指标的分类，梳理出CPU性能分析的指标筛选清单

二、性能工具

掌握CPU的性能指标，还需要知道怎样去获取这些指标，也就是工具的使用

在这里先回顾一下前面的CPU性能工具

2.1 平均负载的案例

首先，平均负载的案例

1. 用uptime查看系统的平均负载
2. 在平均负载升高后，用mpstat和pidstat分别观察了每个CPU和每个进程CPU的使用情况

进而找出了导致平均负载升高的进程，也就是压测工具stress

2.2 上下文切换的案例

第二个，上下文切换的案例

1. 用vmstat查看系统的上下文切换次数和中断次数
2. 然后通过pidstat观察了进程的自愿上下文切换和非自愿上下文切换情况
3. 最后通过pidstat观察了线程的上下文切换情况

找出了上下文切换次数增多的根源，也就是基准测试工具sysbench

2.3 进程CPU使用率的案例

第三个，进程CPU使用率升高的案例

1. 用top查看系统和进程的CPU使用情况，发现CPU使用率升高的进程是php-fpm
2. 用perf top，观察php-fpm的调用链

最终找出CPU升高的根源，也就是库函数sqrt()

2.4 系统CPU使用率的案例

第四个，系统的 CPU 使用率升高的案例

1. 用top观察到了系统CPU升高
2. 通过top和pidstat，找不出高CPU使用率的进程
3. 重新审视top的输出，从CPU使用率不高但处于Running状态的进程入手，找出了可疑之处
4. 通过perf record和perf report

发现原来是短时进程在捣鬼
另外，对于短时进程介绍了一个专门的工具execsnoop，可以实时监控进程调用的外部命令

2.5 不可中断进程和僵尸进程的案例

第五个，不可中断进程和僵尸进程的案例

1. 用top观察到了iowait升高的问题，并发现了大量的不可中断进程和僵尸进程
2. 接着用dstat发现是这是由磁盘读导致
3. 通过 pidstat 找出了相关的进程
4. 用strace查看进程系统调用失败
5. 最终用perf分析进程调用链

发现根源在于磁盘直接 I/O

2.6 软中断的案例

最后一个，软中断的案例

1. 通过top观察到，系统的软中断CPU使用率升高
2. 接着查看/proc/softirqs， 找到了几种变化速率较快的软中断
3. 然后通过sar命令，发现是网络小包的问题
4. 最后再用tcpdump ，找出网络帧的类型和来源

确定是一个SYN FLOOD攻击导致

二、性能指标和性能工具的联系

原来短短几个案例，已经用过十几种CPU性能工具，且每种工具的适用场景还不同。这么多的工具要怎么区分呢？在实际的性能分析中，又该怎么选择呢？

应该从两个不同的维度来理解它们，做到活学活用

2.1 从CPU的性能指标出发

第一个维度，从CPU的性能指标出发
当要查看某个性能指标时，要清楚知道哪些工具可以做到

根据不同的性能指标，对提供指标的性能工具进行分类和理解
这样，在实际排查性能问题时，可以清楚知道什么工具可以提供你想要的指标，而不是毫无根据地挨个尝试

在前面的案例中多次用到了这个思路
比如：用top发现软中断CPU使用率高后，下一步自然就想知道具体的软中断类型，那在哪里可以观察各类软中断的运行情况呢？ 当然是proc文件系统中的/proc/softirqs这个文件

比如：找到的软中断类型是网络接收，那就要继续往网络接收方向思考，系统的网络接收情况是什么样的？什么工具可以查到网络接收情况呢？用的正是dstat

虽然不需要把所有工具背下来，但如果能理解每个指标对应的工具的特性，一定更高效、更灵活地使用

把提供CPU性能指标的工具做成了一个表格，梳理性能指标和性能工具的关系

2.2 从工具出发

第二个维度，从工具出发
当已经安装了某个工具后，要知道这个工具能提供哪些指标

具体到每个工具的使用方法，一般都支持丰富的配置选项
这些配置选项并不用背下来，只要知道有哪些工具、以及这些工具的基本功能是什么就够了。真正要用到的时候，通过man命令，查使用手册就可

同样的，将这些常用工具汇总成了一个表格

三、如何迅速分析CPU的性能瓶颈

有没有什么方法，可以又快又准找出系统瓶颈呢？答案是肯定的

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

举个例子，用户CPU使用率高，应该去排查进程的用户态而不是内核态，因为用户CPU使用率反映的就是用户态的 CPU 使用情况，而内核态的CPU使用情况只会反映到系统CPU使用率上

3.1 常用初步工具

为了缩小排查范围，通常会先运行几个支持指标较多的工具，如top、vmstat和pidstat
为什么是这三个工具呢？仔细看看下面这张图

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

通过这张图可以发现，这三个命令几乎包含了所有重要的CPU性能指标，比如：

1. 从top的输出可以得到各种 CPU 使用率以及僵尸进程和平均负载等信息
2. 从vmstat的输出可以得到上下文切换次数、中断次数、运行状态和不可中断状态的进程数
3. 从 pidstat的输出可以得到进程的用户CPU使用率、系统CPU使用率、以及自愿上下文切换和非自愿上下文切换情况

3.2 栗子

另外，这三个工具输出的很多指标是相互关联的，用虚线表示了它们的关联关系，下面举几个例子更容易理解

• 第一个例子

pidstat输出的进程用户CPU使用率升高，会导致top输出的用户CPU使用率升高
所以，当发现top输出的用户CPU使用率有问题时，可以跟pidstat的输出做对比，观察是否是某个进程导致的问题

而找出导致性能问题的进程后，就要用进程分析工具来分析进程的行为，比如使用strace分析系统调用情况，以及使用perf分析调用链中各级函数的执行情况

• 第二个例子

top输出的平均负载升高，可以跟vmstat输出的运行状态和不可中断状态的进程数做对比，观察是哪种进程导致的负载升高

• 如果是不可中断进程数增多，那就需要做I/O的分析，也就是用dstat或sar等工 具，进一步分析 I/O 的情况

• 如果是运行状态进程数增多，那就需要回到top和pidstat，找出这些处于运行状态的到底是什么进程，然后再用进程分析工具，做进一步分析

• 第三个例子

当发现top输出的软中断CPU使用率升高时，可以查看/proc/softirqs文件中各种类型软中断的变化情况，确定到底是哪种软中断出的问题
比如，发现是网络接收中断导致的问题，那就可以继续用网络分析工具sar和tcpdump分析

保存下上面几张图，作为CPU性能分析的思路图谱，从最核心的这几个工具开始分析调优问题