1. 小声BIBI

    曾几何时，年少无知的我将CPU使用率和负载混为一谈，简单的认为负载高了就是CPU使用率高，直到碰到了一次现网事故时发现CPU的load很高，但是CPU使用率却很低，苦于基础能力薄弱，只能求助大神才将事故解决，痛定思痛，下面就开始学习一些CPU性能相关的基础知识。本博文主要讲CPU的平均负载和简单的问题排查。

2. 前期准备

• 能联通互联网的Linux环境，我使用的是CentOS7
• stress-ng性能压测工具，若机器上没有可以参照如下安装方式（注意机器有没有配置yum源）

yum install -y epel-release
yum install stress-ng -y

• 可选：因为CentOS自带的sysstat版本会比较旧，有些性能参数指标可能会少，所以如果是自己在家学习的话建议可以安装最新版本的sysstat，最新版本为：12.3.4，安装方式如下：

yum install -y git
git clone git://github.com/sysstat/sysstat
cd sysstat
./configure
make &&make install
校验安装版本：sar -V

    注意：生产环境可能不能连通到互联网，可以到github下载到本地然后上传到现网机器安装。

3. 正餐开始

3.1. 平均负载

    首先，我们可以使用最简单的uptime命令来查看当前的CPU负载，结果如下图：

    截图中的load average后跟着的3个数字就分别代表着1分钟，5分钟，15分钟的CPU平均负载。
    使用man uptime我们可以看到其中对CPU平均负载的详细介绍，平均负载是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数，它和 CPU 使用率并没有直接关系。
    可运行状态的进程：指正在使用 CPU 或者正在等待 CPU 的进程，我们日常使用ps aux命令查看到的进程状态为R的其实就是可运行状态的进程。
    不可中断状态的进程：正处于内核态关键流程中的进程，并且这些流程是不可打断的，比如最常见的是等待硬件设备的 I/O 响应，也就是我们在 ps aux命令中看到的 D 状态（Uninterruptible Sleep，也称为 Disk Sleep）的进程。比如，当一个进程向磁盘读写数据时，为了保证数据的一致性，在得到磁盘回复前，它是不能被其他进程或者中断打断的，这个时候的进程就处于不可中断状态。如果此时的进程被打断了，就容易出现磁盘数据与进程数据不一致的问题。所以，不可中断状态实际上是系统对进程和硬件设备的一种保护机制。
    通过以上描述，我们可以想到最理想的情况是每个CPU上都刚好跑着一个进程，这时CPU是得到了充分的利用。    回到刚才我们使用uptime命令查看到的结果，结果中给出了1,5和15分钟的平均负载，那我们通过这3个数据能得出什么结论呢。
举例如下：

• 1，5，15分钟的数值相差不大，说明负载很平稳
• 1分钟的数值远小于15分钟，说明系统近1分钟的CPU负载有降低，要排查下是否有运维动作或业务假死导致CPU负载降低。
• 15分钟数值远小于1分钟数值，说明系统CPU负载开始提升，若持续大于CPU核数则需要特别关注。

  理论说了一堆不如实操一波，我们经常碰到的负载或CPU使用率飙高的情况无非以下三种，CPU密集型进程，IO密集型进程，大量进程等待CPU执行。下面我将构造这三种情况并分析排查，提出我们需要关注的参数。

3.2. CPU密集型进程

• 步骤一：因为我的CPU有两个，所以使用命令：stress-ng --cpu 2 --timeout 600模拟CPU使用率100%的情况
• 步骤二：假设这个时候我们收到了现网CPU负载较高的告警，首先第一反应就是使用top命令或者uptime命令校验是否是误报告警，top命令信息较多，我这里只演示uptime命令，执行watch -d uptime查看CPU负载变化，-d是为了高亮显示变化的数据

  可以看到1分钟的CPU平均负载慢慢的来到了2以上，说明有进程在搞事情，赶紧接下去排查。

• 步骤三：接下来我们第一反应一定是CPU到底咋了，赶紧瞅一眼，这时候sysstat中的sar工具就能给我们提供巨大的帮助，执行命令sar -P ALL 5 100，这个命令的意思是查看每个CPU的详细情况，5秒采集一次，总共采集100次。（PS：sar巨强大，怎么使用参考我之前的博文：运维入门必备Linux sar命令_左撇子帕布-CSDN博客）

  

      这时发现是用户态占用较高，应该是有CPU密集型进程在搞事情，我们赶紧找下是谁干的

• 步骤四：执行命令pidstat -u 5 2（每5秒采集一次，总共采集两次）查看到底是哪个进程在搞事情。

    这时候发现元凶，就是我们刚才使用stress-ngstress进程。
    多哔哔一句：其实生产环境真出事的时候时间就是金钱，直接使用pidstat -u 5 10的命令看就行，为什么不建议使用top命令看呢，因为他只能展示进程对CPU的总体占用，不能区分是对CPU用户态，系统态还是iowait的占用。 

3.3. I/O 密集型进程

• 步骤一:   执行命令stress-ng --hdd 1 --timeout 600来模拟10分钟的IO等待飙高场景。
• 步骤二：与CPU密集型一样，收到告警我们还是执行watch -d uptime检查下是不是误告警
• 步骤三：执行命令sar -P ALL 5 3查看CPU使用情况

    可以看到iowait有明显升高，这时如果你使用top命令查看会发现没有进程对CPU使用率较高，但是平均负载就是很高。

• 执行pidstat -d 5 2看是哪个进程在搞事情，注意这里使用的是参数-d来查看是哪个进程对磁盘读写较多，一看果然是stress-ng进程导致。

3.4. 大量进程等待CPU执行

• 步骤一：执行命令stress-ng --cpu 10 --timeout 600启动10个进程占用CPU
• 步骤二：执行命令watch -d uptime查看平均负载

    可以看到1分钟CPU平均负载已经到了8，而我的机器只有2核，CPU肯定处理不过来。

• 步骤三：执行命令pidstat -u 5 2查看进程对cpu使用情况

    可以看到大量进程%wait列已经飙到80以上，说明进程的大量时间是花费在等待CPU执行上，若现网发生此类情况就赶紧扩容CPU吧。

    注意：这个%wait列是sysstat版本在11.5.5之后才有的，如果想要使用请参照我在前期准备中进行sysstat进行安装

    至此做了浅显的CPU平均负载讲解，走过路过的大神要是看出哪里有问题别惯着赶紧拍砖。