LINUX系统负载的基础概念

一、什么是平均负载？

每次发现系统变慢时，大家通常做的第一件事，会执行 top 或者 uptime 命令，来了解系统的负载情况。例如，敲完uptime，系统会返回一行结果如下

Load average 后面跟着的3个数值，就是我们要说的平均负载，它分别代表着过去1 分钟、5 分钟、15 分钟的平均负载（Load Average）。

平均负载是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数，它和 CPU 使用率并没有直接关系。

可运行状态的进程，是指正在使用 CPU 或者正在等待 CPU 的进程，也就是我们常用 ps 命令看到的，处于 R 状态（Running 或 Runnable）的进程。

不可中断状态的进程，是指正处于内核态关键流程中的进程，并且这些流程是不可打断的，比如最常见的是等待硬件设备的 I/O 响应，也就是我们在 ps 命令中看到的 D 状态（Uninterruptible Sleep，也称为 Disk Sleep）的进程。不可中断状态实际上是系统对进程和硬件设备的一种保护机制。

平均负载其实就是平均活跃进程数。平均活跃进程数，直观上的理解就是单位时间内的活跃进程数，但它实际上是活跃进程数的指数衰减平均值。这个“指数衰减平均”的详细含义你不用计较，这只是系统的一种更快速的计算方式，你把它直接当成活跃进程数的平均值也没问题。

那么，平均负载的值多少才算合理？

平均负载最理想的情况是等于 CPU 个数。所以在评判平均负载时，首先你要知道系统有几个 CPU。Uptime展示的三个不同时间间隔的平均值，其实给我们提供了分析系统负载趋势的数据来源，让我们能更全面、更立体地理解目前的负载状况。

如果 1 分钟、5 分钟、15 分钟的三个值基本相同，或者相差不大，那就说明系统负载很平稳。

但如果 1 分钟的值远小于 15 分钟的值，就说明系统最近 1 分钟的负载在减少，而过去 15 分钟内却有很大的负载。

反过来，如果 1 分钟的值远大于 15 分钟的值，就说明最近 1 分钟的负载在增加，这种增加有可能只是临时性的，也有可能还会持续增加下去，所以就需要持续观察。一旦 1 分钟的平均负载接近或超过了 CPU 的个数，就意味着系统正在发生过载的问题，这时就得分析调查是哪里导致的问题，并要想办法优化了。

实际生产环境中，平均负载多高时，需要我们重点关注？

推荐的方法，是把系统的平均负载监控起来，然后根据更多的历史数据，判断负载的变化趋势。当发现负载有明显升高趋势时，比如说负载翻倍了，则需要去及时做分析和调查。

平均负载与 CPU 使用率的关系？

平均负载代表的是活跃进程数，平均负载高了， CPU 使用率不一定也跟着高。活跃进程数不仅包括了正在使用 CPU 的进程，还包括等待 CPU 和等待 I/O 的进程；而CPU 使用率，是单位时间内 CPU 繁忙情况的统计，跟平均负载并不一定完全对应。有以下三种情况：

CPU 密集型进程，使用大量 CPU 会导致平均负载升高，此时这两者是一致的；

I/O 密集型进程，等待 I/O 也会导致平均负载升高，但 CPU 使用率不一定很高；

大量等待 CPU 的进程调度也会导致平均负载升高，此时的 CPU 使用率也会比较高。

二、CPU上下文切换

Linux 是一个多任务操作系统，它支持远大于 CPU 数量的任务同时运行。当然，这些任务实际上并不是真的在同时运行，而是因为系统在很短的时间内，将 CPU 轮流分配给它们，造成多任务同时运行的错觉。

而在每个任务运行前，CPU 都需要知道任务从哪里加载、又从哪里开始运行，也就是说，需要系统事先帮它设置好 CPU 寄存器和程序计数器（Program Counter，PC）。

CPU 寄存器，是 CPU 内置的容量小、但速度极快的内存。而程序计数器，则是用来存储 CPU 正在执行的指令位置、或者即将执行的下一条指令位置。它们都是 CPU 在运行任何任务前，必须的依赖环境，因此也被叫做 CPU 上下文。

指令寄存器（IR）程序计数器（PC）地址寄存器（AR）数据寄存器（AC）累加寄存器（AC）

CPU 上下文切换，就是先把前一个任务的 CPU 上下文（也就是 CPU 寄存器和程序计数器）保存起来，然后加载新任务的上下文到这些寄存器和程序计数器，最后再跳转到程序计数器所指的新位置，运行新任务。

CPU 的上下文切换就可以分为几个不同的场景，也就是进程上下文切换、线程上下文切换以及中断上下文切换。

进程的上下文切换：

Linux 按照特权等级，把进程的运行空间分为内核空间和用户空间，分别对应着下图中， CPU 特权等级的 Ring 0 和 Ring 3。进程既可以在用户空间运行，又可以在内核空间中运行。进程在用户空间运行时，被称为进程的用户态，而陷入内核空间的时候，被称为进程的内核态。

内核空间（Ring 0）具有最高权限，可以直接访问所有资源；

用户空间（Ring 3）只能访问受限资源，不能直接访问内存等硬件设备，必须通过系统调用陷入到内核中，才能访问这些特权资源。

进程从用户态到内核态的转变，需要通过系统调用来完成。比如，当我们查看文件内容时，就需要多次系统调用来完成：首先调用 open() 打开文件，然后调用 read() 读取文件内容，并调用 write() 将内容写到标准输出，最后再调用 close() 关闭文件。

进程上下文切换，是指从cpu一个进程切换到另一个进程运行。进程是由内核来管理和调度的，进程的切换只能发生在内核态。所以，进程的上下文不仅包括了虚拟内存、栈、全局变量等用户空间的资源，还包括了内核堆栈、寄存器等内核空间的状态。

进程切换时才需要切换上下文，换句话说，只有在进程调度的时候，才需要切换上下文。Linux 为每个 CPU 都维护了一个就绪队列，将活跃进程（即正在运行和正在等待 CPU 的进程）按照优先级和等待 CPU 的时间排序，然后选择最需要 CPU 的进程，也就是优先级最高和等待 CPU 时间最长的进程来运行。

进程在什么时候才会被调度到 CPU 上运行？

为了保证所有进程可以得到公平调度，CPU 时间被划分为一段段的时间片，这些时间片再被轮流分配给各个进程。这样，当某个进程的时间片耗尽了，就会被系统挂起，切换到其它正在等待 CPU 的进程运行。

进程在系统资源不足（比如内存不足）时，要等到资源满足后才可以运行，这个时候进程也会被挂起，并由系统调度其他进程运行。

当进程通过睡眠函数 sleep 这样的方法将自己主动挂起时，自然也会重新调度。

当有优先级更高的进程运行时，为了保证高优先级进程的运行，当前进程会被挂起，由高优先级进程来运行。

发生硬件中断时，CPU 上的进程会被中断挂起，转而执行内核中的中断服务程序。

关于CPU上下文切换，我们需要知道的是：

CPU 上下文切换，是保证 Linux 系统正常工作的核心功能之一，一般情况下不需要我们特别关注。

但过多的上下文切换，会把 CPU 时间消耗在寄存器、内核栈以及虚拟内存等数据的保存和恢复上，从而缩短进程真正运行的时间，导致系统的整体性能大幅下降。

上下文切换的类型，可分自愿上下文切换和非自愿上下文切换：

使用vmstat和pidstat可以观察系统CPU上下文切换情况

如 vmstat 1 5

cs（context switch）是每秒上下文切换的次数。

in（interrupt）则是每秒中断的次数。

r（Running or Runnable）是就绪队列的长度，也就是正在运行和等待 CPU 的进程数。

b（Blocked）则是处于不可中断睡眠状态的进程数。

查看进程的详细情况，可使用pidstat -w 5

cswch，表示每秒自愿上下文切换（voluntary content switches）的次数

nvcswch，表示每秒非自愿上下文切换（no voluntary content switches）的次数

注意: 自愿上下文切换变多了，说明进程都在等待资源，有可能发生了 I/O、内存等其他问题；非自愿上下文切换变多了，说明进程由于时间片已到等原因都在被强制调度，也就是都在争抢 CPU，说明 CPU 的确成了瓶颈。

三、进程的生命周期状态

一个进程被fork出来后，进入就绪态；

当被调度到获得CPU执行时，进入执行态；

如果时间片用完或被强占时，进入就绪态；

资源得不到满足时，进入睡眠态(深度睡眠或浅度睡眠)，比如一个网络程序，在等对方发包，此时不能占着CPU，进入睡眠态，当包发过来时，进程被唤醒，进入就绪态；

如果被暂停，进入停止态；执行完成后，资源释放，此时父进程wait函数还未收到它的信号，就会进入僵死态。

即整个周期可能会涉及的状态有：就绪态，执行态，僵死态，停止态，睡眠态。

四、有关系统调用

为何要有系统调用？

LINUX系统中内核分为用户态和内核态，在用户态下程序不内直接访问内核数据结构或者内核程序，只有在内核态下才可访问。请求内核服务的进程使用系统调用的特殊机制，每个系统调用都设置了一组识别进程请求的参数，通过执行CPU指令完成用户态向内核态的转换。系统调用是应用程序与内核交互的一种方式。系统调用作为一种接口，通过系统调用，应用程序能够进入操作系统内核，从而使用内核提供的各种资源，比如操作硬件，开关中断，改变特权模式等等。

常用系统调用：

控制硬件:如write/read调用。

设置系统状态或读取内核数据——getpid()、getpriority()、setpriority()、sethostname()

进程管理:如 fork()、clone()、execve()、exit()等

系统调用的处理过程

当我们在用户态应用程序中调用一个系统调用函数时，它背后所隐藏的从用户态到内核态的整个处理过程，如下图所示：