遇到服务器卡顿？老司机都会的CPU 性能分析，不允许你不会

相信有工作几年的测试人员，在做测试时，一发现测试环境卡顿，就会想着去看服务器运行状态。怎么看？

可能大脑里第一反应就是用‘top’，执行 top 命令，看啥呢？

你看这个，啥情况？有人能告诉我，为啥 CPU 使用率这么低，但是 load 值却比较高吗？

不知道原因，但是，知道现在系统 load 值很高，所以服务器很卡。

今天，我们就来给大家介绍下，怎么看服务器运行情况。

首先，看服务器的运行情况，我们肯定会去看 CPU 的运行情况。当我们在执行 top 命令的时候，我们会看到有一个 %CPU(s) 这样一行，这一行，就是显示 CPU 的运行情况(默认间隔 3 秒钟更新数据)，其中

us：用户态，未改变优先级的进程占用 CPU 的百分比

sy：系统态，内核空间占用 CPU 百分比

ni：用户态改变优先级的进程占用的 CPU 百分比

id：空闲的时间百分比

wa：空闲&等待 IO 的时间百分比

hi：硬中断时间百分比

si：软中断时间百分比

st：虚拟化时被其余 vm 窃取的时间百分比

这些，我们得知道是什么意思。

然后，我们还需要知道，按下数字键 ‘1’，就会看到 %Cpu(0)..... 这样多行，就可以知道当前有多少个活跃的 CPU(逻辑)。

那么，接下来的问题就是这些数据分别代表什么意思？与 load 又是什么关系？

要想弄明白这两个问题，我们得先知道 CPU 由哪些部分组成及他们之间是怎么工作的。

很多人说，CPU 是由三个部分组成，其实，还不准确，准确来说，应该是由 4 个重要部分组成：计算器、控制器、寄存器和时钟。

计算器，顾名思义，就是 CPU 中进行运算的核心元件，CPU 实现的所有计算，都是由它来完成的。

控制器，就是 CPU 的指挥控制中心，是管理者，做一些指挥调度工作。

寄存器，这个买过电脑的同学应该都熟悉，现在买电脑 CPU 都要看有几级缓存，缓存大小。它是 CPU 中暂存数据的地方，待处理和已经处理的数据，都会暂存在这里。

时钟，这个东西，你说它在吧，它又不在；不在吧，它又在。它做的就是时间片段计时的。计算器，在进行计算的时候，都是有个时间片段的，时间片段到了，不管计算是否完成，计算器，都得去干其他事情，之后，再分配时间片段，来做未完成的事情。时钟，就是这么霸道。

这张图，相信很多同学都见过，非常形象的描述了 CPU 内部元件之间的关系。

接下来，我们就来想一下你们公司的产品服务器，是不是在一台服务器上部署产品服务，服务运行起来，普通用户通过操作端，进行操作，从而驱动你们产品的服务进行计算，输出结果给用户。这个计算，就是在 CPU 内完成的。

开发人员，在实现产品经理要求的功能时，就会写一些代码，这些代码，有的是要自身逻辑运算，有的是需要调系统底层能力支撑，调了系统底层的，我们说要使用系统内核，要用到 CPU 的 sy 系统态，不用调系统底层的，我们就说是用 CPU 的 us 用户态，

从非内核进入内核，再从内核处理完出来到非内核，这是不是要来回的切换。就好比公司的核心保密区和非保密区，你要进进出出，是不是都有严格的审查。这个类比到 CPU，我们叫上下文切换。而这个切换，我们也分自愿上下文切换和非自愿上下文切换，这个大家应该很好理解，主动的进进出出就是自愿上下文，被迫进进出出就是非自愿上下文切换。还有我们前面说的时钟片段，这些，就与 CPU 的 si 软中断，和 CPU 的 hi 硬中断关联上了。

在 CPU 进行计算时，你是不是要给一些资源(如：原始数据)，进入 CPU，计算完之后，再把结果从 CPU 中转移出来，这个资源的进\出，就是资源的 I/O，等待这些资源的时间，就是 CPU 的 wa 等待时间百分比。

一台服务器并不会只部署一个应用服务，当有多个应用服务在运行时，你认为现在的服务器是让它们串行，还是并行？相信不用我说答案，大家都会说肯定是并行，那你们再想想，并行，插队是不是有可能。这种，服务间进程插队的情况，就是 CPU 的 ni 进程优先级切换。

当没有用户使用你们的产品的时候，服务器在歇息，次数就是 CPU 的 id 空闲时间百分比。

好了，大家是否理解了呢？可以对照着第 1 张图，检验一下，看自己是否弄明白了哦！

第二个问题，CPU 的数据与 load 值之间到底什么关系？load 值很大，CPU 的数据就一定高吗？

相信，很多人，在没有看过文章第 1 张图之前，肯定会认为是对的，load 值大，CPU 的使用率就一定高。因为，普通的认识是，CPU 的 us + sy 的值越接近 100，说明 CPU 越繁忙，load 值就应该高，相反，就应该低。其实，在这个里面，存在一个误区。

现在 Linux 服务器的内核，绝大多数都已经升级，超过了 2.6 版本。在 2.6 版的内核中，已经把 load 值的计算方法调整为，所有不可中断睡眠状态的进程，即 load average = CPU 负载 +Disk 负载 + 网络负载 + 其余外设负载，从第 1 张图看，就是包含了我们的 wa 等待负载值。

所以，第 1 张图中，我们能分析出，目前的服务器存在 I/O 问题，是因为服务器频繁在执行数据换进换出，导致 CPU 的 wa 等待资源时间过长，从而出现 load 值过高，系统比较卡顿。

本文作者：柠檬班软件测试（lemonban）——专注于最新最前沿的软件测试技术，解决你的测试技术烦恼，对软件测试感兴趣的朋友赶快关注我们吧！