[root@system]# top
top - 23:39:41 up 8 days, 6:36, 2 users, load average: 0.00, 0.01, 0.05
Tasks: 71 total, 1 running, 70 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 1016168 total, 386208 free, 69620 used, 560340 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 777376 avail Mem
这两个从一定程度上都可以反映一台机器的繁忙程度.
cpu使用率反映的是当前cpu的繁忙程度,忽高忽低的原因在于占用cpu处理时间的进程可能处于io等待状态但却还未释放进入wait。
平均负载(load average)是指某段时间内占用cpu时间的进程和等待cpu时间的进程数,这里等待cpu时间的进程是指等待被唤醒的进程,不包括处于wait状态进程。
以上分析可以看出,一台机器很有可能处于低cpu使用率高负载的情况,因此看机器的繁忙程度应该结合两者,从实际的使用情况观察,自己的一台双核志强2.8GHZ,2G内存的机器在平均负载到50左右,cpu使用率才接近100%(应用有不少io操作),这种情况下应用还算流畅,实际访问延迟不是很高。因此在cpu还空闲的情况下,如何提高io响应是减少负载的关键,很多人认为负载到几十了机器就非常繁忙了,我倒觉得如果这个时候cpu使用率比较低,则负载高可能不能很好说明问题,一旦cpu处理的进程处理完后,那些等待的进程也能立刻得到响应,这种情况下应该优化io读写速度。真到cpu使用率一直90%以上,即使平均负载只有个位数(比如某一个进程一直在运算),那机器其实也已经繁忙了~
其实,在前面的文章中,也有写到cpu使用率低负载高,原因分析 cpu使用率低,但是load很高,load很高的可能是IO
CPU负载的一个类比
判断系统负荷是否过重,必须理解load average的真正含义。下面,我根据"Understanding Linux CPU Load"这篇文章,尝试用最通俗的语言,解释这个问题。
首先,假设最简单的情况,你的电脑只有一个CPU,所有的运算都必须由这个CPU来完成。
那么,我们不妨把这个CPU想象成一座大桥,桥上只有一根车道,所有车辆都必须从这根车道上通过。(很显然,这座桥只能单向通行。)
系统负荷为0,意味着大桥上一辆车也没有。
系统负荷为0.5,意味着大桥一半的路段有车。
系统负荷为1.0,意味着大桥的所有路段都有车,也就是说大桥已经"满"了。但是必须注意的是,直到此时大桥还是能顺畅通行的。
系统负荷为1.7,意味着车辆太多了,大桥已经被占满了(100%),后面等着上桥的车辆为桥面车辆的70%。以此类推,系统负荷2.0,意味着等待上桥的车辆与桥面的车辆一样多;系统负荷3.0,意味着等待上桥的车辆是桥面车辆的2倍。总之,当系统负荷大于1,后面的车辆就必须等待了;系统负荷越大,过桥就必须等得越久。
CPU的系统负荷,基本上等同于上面的类比。大桥的通行能力,就是CPU的最大工作量;桥梁上的车辆,就是一个个等待CPU处理的进程(process)。
如果CPU每分钟最多处理100个进程,那么系统负荷0.2,意味着CPU在这1分钟里只处理20个进程;系统负荷1.0,意味着CPU在这1分钟里正好处理100个进程;系统负荷1.7,意味着除了CPU正在处理的100个进程以外,还有70个进程正排队等着CPU处理。
为了电脑顺畅运行,系统负荷最好不要超过1.0,这样就没有进程需要等待了,所有进程都能第一时间得到处理。很显然,1.0是一个关键值,超过这个值,系统就不在最佳状态了,你要动手干预了。
CPU负载-多处理器
上面,我们假设你的电脑只有1个CPU。如果你的电脑装了2个CPU,会发生什么情况呢?
2个CPU,意味着电脑的处理能力翻了一倍,能够同时处理的进程数量也翻了一倍。
还是用大桥来类比,两个CPU就意味着大桥有两根车道了,通车能力翻倍了。
所以,2个CPU表明系统负荷可以达到2.0,此时每个CPU都达到100%的工作量。推广开来,n个CPU的电脑,可接受的系统负荷最大为n.0。
CPU负载-多核处理器
芯片厂商往往在一个CPU内部,包含多个CPU核心,这被称为多核CPU。
在系统负荷方面,多核CPU与多CPU效果类似,所以考虑系统负荷的时候,必须考虑这台电脑有几个CPU、每个CPU有几个核心。然后,把系统负荷除以总的核心数,只要每个核心的负荷不超过1.0,就表明电脑正常运行。
怎么知道电脑有多少个CPU核心呢?
"cat /proc/cpuinfo"命令,可以查看CPU信息。"grep -c 'model name' /proc/cpuinfo"命令,直接返回CPU的总核心数。
系统负荷的经验法则
1.0是系统负荷的理想值吗?
不一定,系统管理员往往会留一点余地,当这个值达到0.7,就应当引起注意了。经验法则是这样的:
当系统负荷持续大于0.7,你必须开始调查了,问题出在哪里,防止情况恶化。
当系统负荷持续大于1.0,你必须动手寻找解决办法,把这个值降下来。
当系统负荷达到5.0,就表明你的系统有很严重的问题,长时间没有响应,或者接近死机了。你不应该让系统达到这个值。
对于我的机器,有24个core,那么,load多少合适呢?
[root@jiangyi01.sqa.zmf /home/ahao.mah/ALIOS_QA]
#grep 'model name' /proc/cpuinfo | wc -l
24
答案是:
[root@jiangyi01.sqa.zmf /home/ahao.mah/ALIOS_QA]
#echo "0.7*24" |bc
16.8
最佳观察时长
最后一个问题,"load average"一共返回三个平均值----1分钟系统负荷、5分钟系统负荷,15分钟系统负荷,----应该参考哪个值?
如果只有1分钟的系统负荷大于1.0,其他两个时间段都小于1.0,这表明只是暂时现象,问题不大。
如果15分钟内,平均系统负荷大于1.0(调整CPU核心数之后),表明问题持续存在,不是暂时现象。所以,你应该主要观察"15分钟系统负荷",将它作为电脑正常运行的指标。
REF
http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages
http://share.blog.51cto.com/278008/495067
http://www.ruanyifeng.com/blog/2011/07/linux_load_average_explained.html
补充:
系统负荷为0,意味着大桥上一辆车也没有。
系统负荷为0.5,意味着大桥一半的路段有车。
系统负荷为1.0,意味着大桥的所有路段都有车,也就是说大桥已经"满"了。但是必须注意的是,直到此时大桥还是能顺畅通行的。
系统负荷为1.7,意味着车辆太多了,大桥已经被占满了(100%),后面等着上桥的车辆为桥面车辆的70%。以此类推,系统负荷2.0,意味着等待上桥的车辆与桥面的车辆一样多;系统负荷3.0,意味着等待上桥的车辆是桥面车辆的2倍。总之,当系统负荷大于1,后面的车辆就必须等待了;系统负荷越大,过桥就必须等得越久。
CPU的系统负荷,基本上等同于上面的类比。大桥的通行能力,就是CPU的最大工作量;桥梁上的车辆,就是一个个等待CPU处理的进程(process)。
扩展:
原因总结
产生的原因一句话总结就是:等待磁盘I/O完成的进程过多,导致进程队列长度过大,但是cpu运行的进程却很少,这样就体现到负载过大了,cpu使用率低。
下面内容是具体的原理分析:
负载的意义:
负载表示的是“等待进程的平均数”。在上面的进程状态变换过程中,除了running状态,其他都是等待状态,那么其他状态都会加入到负载等待进程中吗?
事实证明,只有进程处于运行态(running)和不可中断状态(interruptible)才会被加入到负载等待进程中,也就是下面这两种情况的进程才会表现为负载的值。
在分析负载为什么高之前先介绍下什么是负载、多任务操作系统、进程调度等相关概念。
扩展:
什么是负载
什么是负载:负载就是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空闲。也就是说,即便是运行处理某任务,也要等到轮到他时才能运行,此类等待状态就表现为程序运行延迟。
uptime输出中包含“load average”的数字
1 2 | [root@localhost ~]# uptime 11:16:38 up 2:06, 4 users, load average: 0.00, 0.02, 0.05 |
Load average从左边起依次是过去1分钟、5分钟、15分钟内,单位时间的等待任务数,也就是表示平均有多少任务正处于等待状态。在load average较高的情况下,这就说明等待运行的任务较多,因此轮到该任务运行的等待时间就会出现较大的延迟,即反映了此时负载较高。
进程调度
什么是进程调度:
进程调度也被一些人称为cpu上下文切换意思是:CPU切换到另一个进程需要保存当前进程的状态并恢复另一个进程的状态:当前运行任务转为就绪(或者挂起、中断)状态,另一个被选定的就绪任务成为当前任务。进程调度包括保存当前任务的运行环境,恢复将要运行任务的运行环境。
在linux内核中,每一个进程都存在一个名为“进程描述符”的管理表。该进程描述符会调整为按照优先级降序排序,已按合理的顺序运行进程(任务)。这个调整即为进程调度器的工作。
调度器划分并管理进程的状态,如:
- 等待分配cpu资源的状态。
- 等待磁盘输入输出完毕的状态。
下面在说一下进程的状态区别:
状态 | 说明 |
运行态(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)和不可中断状态(interruptible)才会被加入到负载等待进程中,也就是下面这两种情况的进程才会表现为负载的值。
- 即便需要立即使用CPU,也还需等待其他进程用完CPU
- 即便需要继续处理,也必须等待磁盘输入输出完成才能进行
下面描述一种直观感受的场景说明为什么只有运行态(running)和可中断状态(interruptible)才会被加入负载。
如:在很占用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故障,那么就会导致进程读写请求一直获取不到资源,从而进程一直是不可中断状态,造成负载很高。