cpu使用率低负载高，原因分析-----举例命令排查过程

原因总结

产生的原因一句话总结就是：等待磁盘I/O完成的进程过多，导致进程队列长度过大，但是cpu运行的进程却很少，这样就体现到负载过大了，cpu使用率低。
下面内容是具体的原理分析：在分析负载为什么高之前先介绍下什么是负载、多任务操作系统、进程调度等相关概念。

什么是负载

什么是负载：负载就是cpu在一段时间内正在处理以及等待cpu处理的进程数之和的统计信息，也就是cpu使用队列的长度统计信息，这个数字越小越好（如果超过CPU核心*0.7就是不正常）
负载分为两大部分：CPU负载、IO负载
例如，假设有一个进行大规模科学计算的程序，虽然该程序不会频繁地从磁盘输入输出，但是处理完成需要相当长的时间。因为该程序主要被用来做计算、逻辑判断等处理，所以程序的处理速度主要依赖于cpu的计算速度。此类cpu负载的程序称为“计算密集型程序”。
还有一类程序，主要从磁盘保存的大量数据中搜索找出任意文件。这个搜索程序的处理速度并不依赖于cpu，而是依赖于磁盘的读取速度，也就是输入输出（input/output,I/O）.磁盘越快，检索花费的时间就越短。此类I/O负载的程序，称为“I/O密集型程序”。

什么是多任务操作系统

Linux操作系统能够同时处理几个不同名称的任务。但是同时运行多个任务的过程中，cpu和磁盘这些有限的硬件资源就需要被这些任务程序共享。即便很短的时间间隔内，需要一边在这些任务之间进行切换到一边进行处理，这就是多任务。
运行中的任务较少的情况下，系统并不是等待此类切换动作的发生。但是当任务增加时，例如任务A正在CPU上执行计算，接下来如果任务B和C也想进行计算，那么就需要等待CPU空闲。也就是说，即便是运行处理某任务，也要等到轮到他时才能运行，此类等待状态就表现为程序运行延迟。

11:48:16 up 34 days, 34 min, 1 user, load average: 9.25, 11.39, 11.11
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root pts/0 119.40.36.230 10:05 0.00s 0.00s 0.00s w

Load average从左边起依次是过去1分钟、5分钟、15分钟内，单位时间的等待任务数，也就是表示平均有多少任务正处于等待状态。在load average较高的情况下，这就说明等待运行的任务较多，因此轮到该任务运行的等待时间就会出现较大的延迟，即反映了此时负载较高。

进程调度

什么是进程调度：
进程调度也被一些人称为cpu上下文切换意思是：CPU切换到另一个进程需要保存当前进程的状态并恢复另一个进程的状态：当前运行任务转为就绪（或者挂起、中断）状态，另一个被选定的就绪任务成为当前任务。进程调度包括保存当前任务的运行环境，恢复将要运行任务的运行环境。
在linux内核中，每一个进程都存在一个名为“进程描述符”的管理表。该进程描述符会调整为按照优先级降序排序，已按合理的顺序运行进程（任务）。这个调整即为进程调度器的工作。
调度器划分并管理进程的状态，如：
等待分配cpu资源的状态。
等待磁盘输入输出完毕的状态。

下面在说一下进程的状态区别：
进程5大状态说明

运行态（running）

只要cpu空闲，任何时候都可以运行

可中断睡眠（interruptible）

为恢复时间无法预测的长时间等待状态。如，来自于键盘设备的输入。

不可中断睡眠:（uninterruptible）

主要为短时间时的等待状态。例如磁盘输入输出等待。被IO阻塞的进程

就绪态（runnable）

响应暂停信号而运行的中断状态。

僵死态（zombie）

进程都是由父进程创建，并销毁；在父进程没有销毁其子进程，被销毁的时候，其子进程由于没有父进程被销毁，就会转变为僵死态。

下面举例来说明进程状态转变：
这里有三个进程A、B、C同时运行。首先，每个进程在生成后都是可运行状态，也就是running状态的开始，而不是现在运行状态，由于在linux内核中无法区别正在运行的状态和可运行的等待状态，下面将可运行状态和正在运行状态都称为running状态。
进程A：running
进程B：running
进程C：running

running的三个进程立即成为调度对象。此时，假设调度器给进程A分配了CPU的运行权限。
进程A：running （正在运行）
进程B：running
进程C：running

进程A分配了CPU，所以进程A开始处理。进程B和C则在此等待进程A迁出CPU。假设进程A进行若干计算之后，需要从磁盘读取数据。那么在A发出读取磁盘数据的请求之后，到请求数据到达之前，将不进行任何工作。此状态称为“因等待I/O操作结束而被阻塞”。在I/O完成处理前，进程A就一直处于等待中，就会转为不可中断睡眠状态（uninterruptible），并不使用CPU。于是调度器查看进程B和进程C的优先级计算结果，将CPU运行权限交给优先级较高的一方。这里假设进程B的优先级高于进程C。
进程A：uninterruptible （等待磁盘输入输出/不可中断状态）
进程B：running （正在运行）
进程C：running

进程B刚开始运行，就需要等待用户的键盘输入。于是B进入等待用户键盘输入状态，同样被阻塞。结果就变成了进程A和进程B都是等待输出，运行进程C。这时进程A和进程B都是等待状态，但是等待磁盘输入输出和等待键盘输入为不同的状态。等待键盘输入是无限期的事件等待，而读取磁盘则是必须短时间内完成的事件等待，这是两种不同的等待状态。各进程状态如下所示：
进程A：uninterruptible （等待磁盘输入输出/不可中断状态）
进程B：interruptible （等待键盘输入输出/可中断状态）
进程C：running （正在运行）

这次假设进程C在运行的过程中，进程A请求的数据从磁盘到达了缓冲装置。紧接着硬盘对内核发起中断信号，内核知道磁盘读取完成，将进程A恢复为可运行状态。
进程A：running （正在运行）
进程B：interruptible （等待键盘输入输出/可中断状态）
进程C：running （正在运行）

此后进程C也会变为某种等待状态。如CPU的占用时间超出了上限、任务结束、进入I/O等待。一旦满足这些条件，调度器就可以完成从进程C到进程A的进程状态切换。

负载的意义：

负载表示的是“等待进程的平均数”。在上面的进程状态变换过程中，除了running状态，其他都是等待状态，那么其他状态都会加入到负载等待进程中吗？
事实证明，只有进程处于运行态（running）和不可中断状态（uninterruptible）才会被加入到负载等待进程中，也就是下面这两种情况的进程才会表现为负载的值。
即便需要立即使用CPU，也还需等待其他进程用完CPU
即便需要继续处理，也必须等待磁盘输入输出完成才能进行

下面描述一种直观感受的场景说明为什么只有运行态（running）和不可中断状态（uninterruptible）才会被加入负载。

如：在很占用CPU资源的处理中，例如在进行动画编码的过程中，虽然想进行其他相同类型的处理，结果系统反映却变得很慢，还有从磁盘读取大量数据时，系统的反映也同样会变的很慢。但是另一方面，无论有多少等待键盘输入输出操作的进程，也不会让系统响应变慢。
什么场景会造成CPU低而负载确很高呢？
通过上面的具体分析负载的意义就很明显了，负载总结为一句话就是：需要运行处理但又必须等待队列前的进程处理完成的进程个数。具体来说，也就是如下两种情况：
等待被授权予CPU运行权限的进程
等待磁盘I/O完成的进程

cpu低而负载高也就是说等待磁盘I/O完成的进程过多，就会导致队列长度过大，这样就体现到负载过大了，但实际是此时cpu被分配去执行别的任务或空闲，具体场景有如下几种。

场景一：磁盘读写请求过多就会导致大量I/O等待

上面说过，cpu的工作效率要高于磁盘，而进程在cpu上面运行需要访问磁盘文件，这个时候cpu会向内核发起调用文件的请求，让内核去磁盘取文件，这个时候会切换到其他进程或者空闲，这个任务就会转换为不可中断睡眠状态。当这种读写请求过多就会导致不可中断睡眠状态的进程过多，从而导致负载高，cpu低的情况。

场景二：MySQL中存在没有索引的语句或存在死锁等情况

我们都知道MySQL的数据是存储在硬盘中，如果需要进行sql查询，需要先把数据从磁盘加载到内存中。当在数据特别大的时候，如果执行的sql语句没有索引，就会造成扫描表的行数过大导致I/O阻塞，或者是语句中存在死锁，也会造成I/O阻塞，从而导致不可中断睡眠进程过多，导致负载过大。
具体解决方法可以在MySQL中运行show full processlist命令查看线程等待情况，把其中的语句拿出来进行优化。

场景三：外接硬盘故障，常见有挂了NFS，但是NFS server故障

比如我们的系统挂载了外接硬盘如NFS共享存储，经常会有大量的读写请求去访问NFS存储的文件，如果这个时候NFS Server故障，那么就会导致进程读写请求一直获取不到资源，从而进程一直是不可中断状态，造成负载很高。

命令排查

Linux的负载高，主要是由于CPU使用、内存使用、IO消耗三部分构成。任意一项使用过多，都将导致服务器负载的急剧攀升。

查看机器负载

在Linux机器上，有多个命令都可以查看机器的负载信息。其中包括uptime、top、w等。

uptime命令
uptime命令能够打印系统总共运行了多长时间和系统的平均负载。uptime命令可以显示的信息显示依次为：现在时间、系统已经运行了多长时间、目前有多少登陆用户、系统在过去的1分钟、5分钟和15分钟内的平均负载。
 

➜  ~ uptime
13:29  up 23:41, 3 users, load averages: 1.74 1.87 1.97

这行信息的后半部分，显示"load average"，它的意思是"系统的平均负荷"，里面有三个数字，我们可以从中判断系统负荷是大还是小。

1.74 1.87 1.97 这三个数字的意思分别是1分钟、5分钟、15分钟内系统的平均负荷。我们一般表示为load1、load5、load15。

w命令
w命令的主要功能其实是显示目前登入系统的用户信息。但是与who不同的是，w命令功能更加强大，w命令还可以显示：当前时间，系统启动到现在的时间，登录用户的数目，系统在最近1分钟、5分钟和15分钟的平均负载。然后是每个用户的各项数据，项目显示顺序如下：登录帐号、终端名称、远 程主机名、登录时间、空闲时间、JCPU、PCPU、当前正在运行进程的命令行。
 

➜  ~ w
14:08  up 23:41, 3 users, load averages: 1.74 1.87 1.97
USER     TTY      FROM              LOGIN@  IDLE WHAT
hollis   console  -                六14   23:40 -
hollis   s000     -                六14   20:24 -zsh
hollis   s001     -                六15       - w

从上面的w命令的结果可以看到，当前系统时间是14:08，系统启动到现在经历了23小时41分钟，共有3个用户登录。系统在近1分钟、5分钟和15分钟的平均负载分别是1.74 1.87 1.97。这和uptime得到的结果相同。 下面还打印了一些登录的用户的各项数据，不详细介绍了。

top命令

top命令是Linux下常用的性能分析工具，能够实时显示系统中各个进程的资源占用状况，类似于Windows的任务管理器。

➜  ~ top
Processes: 244 total, 3 running, 9 stuck, 232 sleeping, 1484 threads
14:16:01 Load Avg: 1.74, 1.87, 1.97  CPU usage: 8.0% user, 6.79% sys, 85.19% idle   SharedLibs: 116M resident, 16M data, 14M linkedit. MemRegions: 66523 total, 2152M resident, 50M private, 930M shared.
PhysMem: 7819M used (1692M wired), 370M unused. VM: 682G vsize, 533M framework vsize, 6402060(0) swapins, 7234356(0) swapouts. Networks: packets: 383006/251M in, 334448/60M out.
Disks: 1057821/38G read, 350852/40G written.
 
PID    COMMAND      %CPU TIME     #TH   #WQ  #PORT MEM    PURG   CMPRS  PGRP  PPID  STATE    BOOSTS          %CPU_ME %CPU_OTHRS UID  FAULTS    COW    MSGSENT   MSGRECV   SYSBSD    SYSMACH   CSW
30845  top          3.0  00:00.49 1/1   0    21    3632K  0B     0B     30845 1394  running  *0[1]           0.00000 0.00000    0    3283+     112    203556+   101770+   8212+     119901+   823+
30842  Google Chrom 0.0  00:47.39 17    0    155   130M   0B     0B     1146  1146  sleeping *0[1]           0.00000 0.00000    501  173746    2697   117678    37821     364228    444830    310043

上面的输出结果中，Load Avg: 1.74, 1.87, 1.97显示的就是负载信息。

机器正常负载范围

对于机器的Load到底多少算正常的问题，一直都是很有争议的，不同人有着不同的理解。对于单个CPU，有人认为如果Load超过0.7就算是超出正常范围了。也有人认为只要不超过1都没问题。也有人认为，单个CPU的负载在2以下都可以接受。

为什么会有这么多不同的理解呢，是因为不同的机器除了CPU影响之外还有其他因素的影响，运行的程序、机器内存、甚至是机房温度等都有可能有区别。

比如，有些机器用于定时执行大量的跑批任务，这个时间段内，Load可能会飙的比较高。而其他时间可能会比较低。那么这段飙高时间我们要不要去排查问题呢？

我的建议是，最好根据自己机器的实际情况，建立一个指标的基线（如近一个月的平均值），只要日常的load在基线上下范围内不太大都可以接收，如果差距太多可能就要人为介入检查了。

但是，总要有个建议的阈值吧，关于这个值。阮一峰在自己的博客中有过以下建议：

当系统负荷持续大于0.7，你必须开始调查了，问题出在哪里，防止情况恶化。

当系统负荷持续大于1.0，你必须动手寻找解决办法，把这个值降下来。

当系统负荷达到5.0，就表明你的系统有很严重的问题，长时间没有响应，或者接近死机了。你不应该让系统达到这个值。

以上指标都是基于单CPU的，但是现在很多电脑都是多核的。所以，对一般的系统来说，是根据cpu数量去判断系统是否已经过载（Over Load）的。如果我们认为0.7算是单核机器负载的安全线的话，那么四核机器的负载最好保持在3(4*0.7 = 2.8)以下。

还有一点需要提一下，在Load Avg的指标中，有三个值，1分钟系统负荷、5分钟系统负荷，15分钟系统负荷。我们在排查问题的时候也是可以参考这三个值的。

一般情况下，1分钟系统负荷表示最近的暂时现象。15分钟系统负荷表示是持续现象，并非暂时问题。如果load15较高，而load1较低，可以认为情况有所好转。反之，情况可能在恶化。

如何降低负载

导致负载高的原因可能很复杂，有可能是硬件问题也可能是软件问题。

如果是硬件问题，那么说明机器性能确实就不行了，那么解决起来很简单，直接换机器就可以了。

前面我们提过，CPU使用、内存使用、IO消耗都可能导致负载高。如果是软件问题，有可能由于Java中的某些线程被长时间占用、大量内存持续占用等导致。建议从以下几个方面排查代码问题：

1、是否有内存泄露导致频繁GC 

2、是否有死锁发生 

3、是否有大字段的读写 

4、会不会是数据库操作导致的，排查SQL语句问题。

这里还有个建议，如果发现线上机器Load飙高，可以考虑先把堆栈内存dump下来后，进行重启，暂时解决问题，然后再考虑回滚和排查问题。
 

Java Web应用Load飙高排查思路

1、使用uptime查看当前load，发现load飙高。

➜  ~ uptime
13:29  up 23:41, 3 users, load averages: 10 10 10

 2、使用top命令，查看占用CPU较高的进程ID。

➜  ~ top
PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
1893 admin     20   0 7127m 2.6g  38m S 181.7 32.6  10:20.26 java

发现PID为1893的进程占用CPU 181%。而且是一个Java进程，基本断定是软件问题。

3、使用 top命令，查看具体是哪个线程占用率较高

➜  ~ top -Hp 1893
PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
4519 admin     20   0 7127m 2.6g  38m R 18.6 32.6   0:40.11 java

4、使用printf命令查看这个线程的16进制

➜  ~ printf %x 4519
11a7

5、使用jstack命令查看当前线程正在执行的方法。

➜  ~ jstack 1893 |grep -A 200 11a7
"thread-5" #500 daemon prio=10 os_prio=0 tid=0x00007f632314a800 nid=0x11a2 runnable [0x000000005442a000]
java.lang.Thread.State: RUNNABLE
at sun.misc.URLClassPath$Loader.findResource(URLClassPath.java:684)
at sun.misc.URLClassPath.findResource(URLClassPath.java:188)
at java.net.URLClassLoader$2.run(URLClassLoader.java:569)
at java.net.URLClassLoader$2.run(URLClassLoader.java:567)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findResource(URLClassLoader.java:566)
at org.hibernate.validator.internal.xml.ValidationXmlParser.getInputStreamForPath(ValidationXmlParser.java:248)
at com.hollis.test.util.BeanValidator.validate(BeanValidator.java:30)

从上面的线程的栈日志中，可以发现，当前占用CPU较高的线程正在执行我代码的com.hollis.test.util.BeanValidator.validate(BeanValidator.java:30) 类。那么就可以去排查这个类是否用法有问题了。

6、还可以使用jstat来查看GC情况，看看是否有频繁FGC，然后再使用jmap来dump内存，查看是否存在内存泄露。