理解Linux load average(负载量)
2018-10-04 22:23:19 
阿炯
在Linux及其他类Unix的系统中，常用该系统正在进行的运算工作量来衡量其系统负载(System Load)。一个完全空闲的系统，它的负载(System Load)标记为0；每一个正在运行或者正在等待CPU资源的进程，会导致平均负载(System Load)加1。所以如果一个系统的负载是3，就是说有3个进程正在使用或者正在等待CPU资源。Load Average的概念源自UNIX系统，虽然各家的公式不尽相同，但都是用于衡量正在使用CPU的进程数量和正在等待CPU的进程数量，一句话就是runnable processes的数量。所以load average可以作为CPU瓶颈的参考指标，如果大于CPU的数量，说明CPU可能不够用了。
因为系统负载(System Load)是不断变化的，所以显示特定时刻的系统负载(System Load)意义不大。相反，Linux显示平均负载(Load Average)： 在一定的时间段内，系统的负载的平均数。在Linux系统中，我们一般使用uptime命令查看(w命令和top命令也行)。从手册中查到，它们的意思分别是1分钟、5分钟、15分钟内系统的平均负载。如果继续看手册，它还会告诉你，当CPU完全空闲的时候，平均负载为0；当CPU工作量饱和的时候，平均负载为1。那么很显然，"load average"的值越低，比如等于0.2或0.3，就说明电脑的工作量越小，系统负载比较轻。
系统平均负载被定义为在特定时间间隔内运行队列中(在CPU上运行或者等待运行多少进程)的平均进程数，如果一个进程满足以下条件则其就会位于运行队列中：
- 它没有在等待I/O操作的结果
- 它没有主动进入等待状态(也就是没有调用'wait')
- 没有被停止(例如：等待终止)
对于单核系统，管理员一般认为load average低于0.7是安全的，load average接近1表明CPU在全力运作。如果再有额外的计算请求，CPU就会过载，系统运行效率就会减慢。当load average大于5是，系统已经有严重的问题了，进程的切换大大降低了CPU运行效率，管理员需要马上进行干预，长时间没有响应或者接近死机了。你不应该让系统达到这个值。
对于多核系统，CPU处理能力扩大n倍，对应load average 的安全值也扩大n倍。比如：对于双核系统，load average 等于2 表明系统接近CPU全负载；对于四核系统，load average 等于4表明系统全负载。
最佳观察时长
最后一个问题，"load average"一共返回三个平均值----1分钟系统负载、5分钟系统负载，15分钟系统负载，应该参考哪个值？
如果只有1分钟的系统负载大于1.0，其他两个时间段都小于1.0，这表明只是暂时现象，问题不大。如果15分钟内，平均系统负载大于1.0(调整CPU核心数之后)，表明问题持续存在，不是暂时现象。所以，你应该主要观察"15分钟系统负载"，将它作为电脑正常运行的指标。
多核与多处理器
我们来讨论下多核心处理器与多处理器的区别。从性能的角度上理解，一台主机拥有多核心的处理器与另台拥有同样数目的处理性能基本上可以认为是相差无几。当然实际情况会复杂得多，不同数量的缓存、处理器的频率等因素都可能造成性能的差异。但即便这些因素造成的实际性能稍有不同，其实系统还是以处理器的核心数量计算负载均值 。这使我们有了两个新的法则：
"有多少核心即为有多少负载"法则： 在多核处理中，你的系统均值不应该高于处理器核心的总数量。
"核心的核心"法则：核心分布在分别几个单个物理处理中并不重要，其实两颗四核的处理器等于四个双核处理器等于八个单处理器，所以它应该有八个处理器内核。
在Linux中，进程分为三种状态，一种是阻塞的进程blocked process，一种是可运行的进程runnable process，另外就是正在运行的进程running process。当进程阻塞时，进程会等待I/O设备的数据或者系统调用。进程可运行状态时，它处在一个运行队列run queue中，与其他可运行进程争夺CPU时间。 系统的load是指正在运行running one和准备好运行runnable one的进程的总数。比如现在系统有2个正在运行的进程，3个可运行进程，那么系统的load就是5。load average就是一定时间内的load数量。
一般来说只要每个CPU的当前活动进程数不大于3那么系统的性能就是良好的，如果每个CPU的任务数大于5，那么就表示这台机器的性能有严重问题。对于上面的例子来说，假设系统有两个CPU，那么其每个CPU的当前任务数为：8.13/2=4.065。这表示该系统的性能是可以接受的。
Linux上的load average除了包括正在使用CPU的进程数量和正在等待CPU的进程数量之外，还包括uninterruptible sleep的进程数量。通常等待IO设备、等待网络的时候，进程会处于uninterruptible sleep状态。Linux设计者的逻辑是，uninterruptible sleep应该都是很短暂的，很快就会恢复运行，所以被等同于runnable。然而uninterruptible sleep即使再短暂也是sleep，何况现实世界中uninterruptible sleep未必很短暂，大量的、或长时间的uninterruptible sleep通常意味着IO设备遇到了瓶颈。众所周知，sleep状态的进程是不需要CPU的，即使所有的CPU都空闲，正在sleep的进程也是运行不了的，所以sleep进程的数量绝对不适合用作衡量CPU负载的指标，Linux把uninterruptible sleep进程算进load average的做法直接颠覆了load average的本来意义。所以在Linux系统上，load average这个指标基本失去了作用，因为你不知道它代表什么意思，当看到load average很高的时候，你不知道是runnable进程太多还是uninterruptible sleep进程太多，也就无法判断是CPU不够用还是IO设备有瓶颈。
Most UNIX systems count only processes in the running (on CPU) or runnable (waiting for CPU) states. However, Linux also includes processes in uninterruptible sleep states (usually waiting for disk activity), which can lead to markedly different results if many processes remain blocked in I/O due to a busy or stalled I/O system.
并附上RHEL7中对负载的计算参考公式
kernel/sched/core.c:
====================
/*
* Global load-average calculations
*
* We take a distributed and async approach to calculating the global load-avg
* in order to minimize overhead.
*
* The global load average is an exponentially decaying average of nr_running +
* nr_uninterruptible.
*
* Once every LOAD_FREQ:
*
* nr_active = 0;
* for_each_possible_cpu(cpu)
* nr_active += cpu_of(cpu)->nr_running + cpu_of(cpu)->nr_uninterruptible;
*
* avenrun[n] = avenrun[0] * exp_n + nr_active * (1 - exp_n)
*
* Due to a number of reasons the above turns in the mess below:
*
* - for_each_possible_cpu() is prohibitively expensive on machines with
* serious number of cpus, therefore we need to take a distributed approach
* to calculating nr_active.
*
* \Sum_i x_i(t) = \Sum_i x_i(t) - x_i(t_0) | x_i(t_0) := 0
* = \Sum_i { \Sum_j=1 x_i(t_j) - x_i(t_j-1) }
*
* So assuming nr_active := 0 when we start out -- true per definition, we
* can simply take per-cpu deltas and fold those into a global accumulate
* to obtain the same result. See calc_load_fold_active().
*
* Furthermore, in order to avoid synchronizing all per-cpu delta folding
* across the machine, we assume 10 ticks is sufficient time for every
* cpu to have completed this task.
*
* This places an upper-bound on the IRQ-off latency of the machine. Then
* again, being late doesn't loose the delta, just wrecks the sample.
*
* - cpu_rq()->nr_uninterruptible isn't accurately tracked per-cpu because
* this would add another cross-cpu cacheline miss and atomic operation
* to the wakeup path. Instead we increment on whatever cpu the task ran
* when it went into uninterruptible state and decrement on whatever cpu
* did the wakeup. This means that only the sum of nr_uninterruptible over
* all cpus yields the correct result.
*
* This covers the NO_HZ=n code, for extra head-aches, see the comment below.
*/
参考来源：
Load_(computing)
理解Linux系统负荷
Linux load average负载量分析与解决思路
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空闲。也就是说，即便是运行处理某任务，也要等到轮到他时才能运行，此类等待状态就表现为程序运行延迟。
uptime输出中包含“load average”的数字
# uptime
21:16:38 up 2:06, 3 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服务器故障，那么就会导致进程读写请求一直获取不到资源，从而进程一直是不可中断状态，造成负载很高。
因为系统负载(System Load)是不断变化的，所以显示特定时刻的系统负载(System Load)意义不大。相反，Linux显示平均负载(Load Average)： 在一定的时间段内，系统的负载的平均数。在Linux系统中，我们一般使用uptime命令查看(w命令和top命令也行)。从手册中查到，它们的意思分别是1分钟、5分钟、15分钟内系统的平均负载。如果继续看手册，它还会告诉你，当CPU完全空闲的时候，平均负载为0；当CPU工作量饱和的时候，平均负载为1。那么很显然，"load average"的值越低，比如等于0.2或0.3，就说明电脑的工作量越小，系统负载比较轻。
系统平均负载被定义为在特定时间间隔内运行队列中(在CPU上运行或者等待运行多少进程)的平均进程数，如果一个进程满足以下条件则其就会位于运行队列中：
- 它没有在等待I/O操作的结果
- 它没有主动进入等待状态(也就是没有调用'wait')
- 没有被停止(例如：等待终止)
对于单核系统，管理员一般认为load average低于0.7是安全的，load average接近1表明CPU在全力运作。如果再有额外的计算请求，CPU就会过载，系统运行效率就会减慢。当load average大于5是，系统已经有严重的问题了，进程的切换大大降低了CPU运行效率，管理员需要马上进行干预，长时间没有响应或者接近死机了。你不应该让系统达到这个值。
对于多核系统，CPU处理能力扩大n倍，对应load average 的安全值也扩大n倍。比如：对于双核系统，load average 等于2 表明系统接近CPU全负载；对于四核系统，load average 等于4表明系统全负载。
最佳观察时长
最后一个问题，"load average"一共返回三个平均值----1分钟系统负载、5分钟系统负载，15分钟系统负载，应该参考哪个值？
如果只有1分钟的系统负载大于1.0，其他两个时间段都小于1.0，这表明只是暂时现象，问题不大。如果15分钟内，平均系统负载大于1.0(调整CPU核心数之后)，表明问题持续存在，不是暂时现象。所以，你应该主要观察"15分钟系统负载"，将它作为电脑正常运行的指标。
多核与多处理器
我们来讨论下多核心处理器与多处理器的区别。从性能的角度上理解，一台主机拥有多核心的处理器与另台拥有同样数目的处理性能基本上可以认为是相差无几。当然实际情况会复杂得多，不同数量的缓存、处理器的频率等因素都可能造成性能的差异。但即便这些因素造成的实际性能稍有不同，其实系统还是以处理器的核心数量计算负载均值 。这使我们有了两个新的法则：
"有多少核心即为有多少负载"法则： 在多核处理中，你的系统均值不应该高于处理器核心的总数量。
"核心的核心"法则：核心分布在分别几个单个物理处理中并不重要，其实两颗四核的处理器等于四个双核处理器等于八个单处理器，所以它应该有八个处理器内核。
在Linux中，进程分为三种状态，一种是阻塞的进程blocked process，一种是可运行的进程runnable process，另外就是正在运行的进程running process。当进程阻塞时，进程会等待I/O设备的数据或者系统调用。进程可运行状态时，它处在一个运行队列run queue中，与其他可运行进程争夺CPU时间。 系统的load是指正在运行running one和准备好运行runnable one的进程的总数。比如现在系统有2个正在运行的进程，3个可运行进程，那么系统的load就是5。load average就是一定时间内的load数量。
一般来说只要每个CPU的当前活动进程数不大于3那么系统的性能就是良好的，如果每个CPU的任务数大于5，那么就表示这台机器的性能有严重问题。对于上面的例子来说，假设系统有两个CPU，那么其每个CPU的当前任务数为：8.13/2=4.065。这表示该系统的性能是可以接受的。
Linux上的load average除了包括正在使用CPU的进程数量和正在等待CPU的进程数量之外，还包括uninterruptible sleep的进程数量。通常等待IO设备、等待网络的时候，进程会处于uninterruptible sleep状态。Linux设计者的逻辑是，uninterruptible sleep应该都是很短暂的，很快就会恢复运行，所以被等同于runnable。然而uninterruptible sleep即使再短暂也是sleep，何况现实世界中uninterruptible sleep未必很短暂，大量的、或长时间的uninterruptible sleep通常意味着IO设备遇到了瓶颈。众所周知，sleep状态的进程是不需要CPU的，即使所有的CPU都空闲，正在sleep的进程也是运行不了的，所以sleep进程的数量绝对不适合用作衡量CPU负载的指标，Linux把uninterruptible sleep进程算进load average的做法直接颠覆了load average的本来意义。所以在Linux系统上，load average这个指标基本失去了作用，因为你不知道它代表什么意思，当看到load average很高的时候，你不知道是runnable进程太多还是uninterruptible sleep进程太多，也就无法判断是CPU不够用还是IO设备有瓶颈。
Most UNIX systems count only processes in the running (on CPU) or runnable (waiting for CPU) states. However, Linux also includes processes in uninterruptible sleep states (usually waiting for disk activity), which can lead to markedly different results if many processes remain blocked in I/O due to a busy or stalled I/O system.
并附上RHEL7中对负载的计算参考公式
kernel/sched/core.c:
====================
/*
* Global load-average calculations
*
* We take a distributed and async approach to calculating the global load-avg
* in order to minimize overhead.
*
* The global load average is an exponentially decaying average of nr_running +
* nr_uninterruptible.
*
* Once every LOAD_FREQ:
*
* nr_active = 0;
* for_each_possible_cpu(cpu)
* nr_active += cpu_of(cpu)->nr_running + cpu_of(cpu)->nr_uninterruptible;
*
* avenrun[n] = avenrun[0] * exp_n + nr_active * (1 - exp_n)
*
* Due to a number of reasons the above turns in the mess below:
*
* - for_each_possible_cpu() is prohibitively expensive on machines with
* serious number of cpus, therefore we need to take a distributed approach
* to calculating nr_active.
*
* \Sum_i x_i(t) = \Sum_i x_i(t) - x_i(t_0) | x_i(t_0) := 0
* = \Sum_i { \Sum_j=1 x_i(t_j) - x_i(t_j-1) }
*
* So assuming nr_active := 0 when we start out -- true per definition, we
* can simply take per-cpu deltas and fold those into a global accumulate
* to obtain the same result. See calc_load_fold_active().
*
* Furthermore, in order to avoid synchronizing all per-cpu delta folding
* across the machine, we assume 10 ticks is sufficient time for every
* cpu to have completed this task.
*
* This places an upper-bound on the IRQ-off latency of the machine. Then
* again, being late doesn't loose the delta, just wrecks the sample.
*
* - cpu_rq()->nr_uninterruptible isn't accurately tracked per-cpu because
* this would add another cross-cpu cacheline miss and atomic operation
* to the wakeup path. Instead we increment on whatever cpu the task ran
* when it went into uninterruptible state and decrement on whatever cpu
* did the wakeup. This means that only the sum of nr_uninterruptible over
* all cpus yields the correct result.
*
* This covers the NO_HZ=n code, for extra head-aches, see the comment below.
*/
参考来源：
Load_(computing)
理解Linux系统负荷
Linux load average负载量分析与解决思路
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空闲。也就是说，即便是运行处理某任务，也要等到轮到他时才能运行，此类等待状态就表现为程序运行延迟。
uptime输出中包含“load average”的数字
# uptime
21:16:38 up 2:06, 3 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服务器故障，那么就会导致进程读写请求一直获取不到资源，从而进程一直是不可中断状态，造成负载很高。