CPU load过高产生的原因及排查（转）

转自：http://m.blog.csdn.net/canot/article/details/78079085

 

什么是cpu load 值

top命令中显示的load average即为最近1分钟、5分钟和15分钟的系统平均负载。 

系统平均负载被定义为在特定时间间隔内运行队列中(在CPU上运行或者等待运行多少进程)的平均进程数。如果一个进程满足以下条件则其就会位于运行队列中：

• 它没有在等待I/O操作的结果
• 它没有主动进入等待状态(也就是没有调用’wait’)
• 没有被停止(例如：等待终止)

在Linux中，进程分为三种状态，一种是阻塞的进程blocked process(等待I/O设备的数据或者系统调)，一种是可运行的进程runnable process，另外就是正在运行的进程running process。

进程可运行状态时，它处在一个运行队列run queue中，与其他可运行进程争夺CPU时间。 系统的load是指正在运行和准备好运行的进程的总数。比如现在系统有2个正在运行的进程，3个可运行进程，那么系统的load就是5。load average就是一定时间内的load数量。

什么因素构成了cpu load的大小

衡量CPU 系统负载的指标是load,load 就是对计算机系统能够承担的多少负载的度量,简单的说是进程队列的长度。请求大于当前的处理能力，会出现等待，引起load升高。 
对于本文刚刚开头显示的 load average 0.21 0.10 0.03

很多人会这样理解负载均值：三个数分别代表不同时间段的系统平均负载(一分钟、五 分钟、以及十五分钟)，它们的数字当然是越小越好。数字越高，说明服务器的负载越大，这也可能是服务器出现某种问题的信号。而事实不完全如此，是什么因素构成了负载均值的大小，以及如何区分它们目前的状况是 “好”还是“糟糕”?什么时候应该注意哪些不正常的数值?

回答这些问题之前，首先需要了解下这些数值背后的些知识。我们先用最简单的例子说明， 一台只配备一块单核处理器的服务器。

行车过桥

　　一只单核的处理器可以形象得比喻成一条单车道。设想下，你现在需要收取这条道路的过桥费 — 忙于处理那些将要过桥的车辆。你首先当然需要了解些信息，例如车辆的载重、以及 还有多少车辆正在等待过桥。如果前面没有车辆在等待，那么你可以告诉后面的司机通过。 如果车辆众多，那么需要告知他们可能需要稍等一会。

　　因此，需要些特定的代号表示目前的车流情况，例如：

　　0.00 表示目前桥面上没有任何的车流。 实际上这种情况与 0.00 和 1.00 之间是相同的，总而言之很通畅，过往的车辆可以丝毫不用等待的通过。

　　1.00 表示刚好是在这座桥的承受范围内。 这种情况不算糟糕，只是车流会有些堵，不过这种情况可能会造成交通越来越慢。 
　　 
　　超过 1.00，那么说明这座桥已经超出负荷，交通严重的拥堵。 那么情况有多糟糕? 例如 2.00 的情况说明车流已经超出了桥所能承受的一倍，那么将有多余过桥一倍的车辆正在焦急的等待。3.00 的话情况就更不妙了，说明这座桥基本上已经快承受不了，还有超出桥负载两倍多的车辆正在等待。 
　　上面的情况和处理器的负载情况非常相似。一辆汽车的过桥时间就好比是处理器处理某线程 的实际时间。Unix 系统定义的进程运行时长为所有处理器内核的处理时间加上线程在队列中等待的时间。

　　和收过桥费的管理员一样，你当然希望你的汽车(操作)不会被焦急的等待。所以，理想状态 下，都希望负载平均值小于 1.00 。当然不排除部分峰值会超过 1.00，但长此以往保持这 个状态，就说明会有问题，这时候你应该会很焦急。 
“所以你说的理想负荷为 1.00 ?”嗯，这种情况其实并不完全正确。负荷 1.00 说明系统已经没有剩余的资源了。在实际情况中 ，有经验的系统管理员都会将这条线划在 0.70。如果长期你的系统负载在 0.70 上下，那么你需要在事情变得更糟糕之前，花些时间了解其原因。

多核处理器: 系统还是以处理器的核心数量计算负载均值 
在多核处理中，你的系统均值不应该高于处理器核心的总数量。继续针对上述的汽车过桥问题，如果是双核CPU，那么负载在2.0才是负载满额。如下是对于双核处理器的输出

uptime
17:57  up 22 days,  8:29, 3 users, load averages: 2.04 2.04 2.01

• 1
• 2

cpu load 过高原因以及排查

造成cpu load过高的原因.从编程语言层次上full gc次数的增大或死循环都有可能造成cpu load 增高

具体的排查一句话描述就是

首先要找到哪几个线程在占用cpu,之后再通过线程的id值在堆栈文件中查找具体的线程，看看出来什么问题。

• 1

寻找最占CPU的进程

• 通过命令 ps ux
• 通过top -c命令显示进程运行信息列表 (按键P按CPU占有资源排序)

寻找最耗CPU的线程

• top -Hp 进程ID 显示一个进程ID的线程运行信息列表 (按键P按CPU占有资源排序) 
  如果该进程是java进程，需要具体查看是哪段代码造成的CPU负载过高，根据上述获得到的线程ID可以使用JDK下的jstack来查看堆栈。

由于在堆栈中线程id是用16进制表示的，因此可以将上述线程转化成16进制的表示。