1、uptime

查看平均负载

  1. $ uptime
  2. 02:34:03 up 2 days, 20:14, 1 user, load average: 0.63, 0.83, 0.88

每列输出的含义

  1. 02:34:03 //当前时间
  2. up 2 days, 20:14 //系统运行时间
  3. 1 user //正在登录用户数
 # 过去1分钟、5分钟、15分钟的平均负载（Load Average）
load average: 0.63, 0.83, 0.88

2、理解

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

  • 可运行状态：是指正在使用CPU或者正在等待CPU的进程，也就是常用 ps 命令看到的，处于 R 状态(Running或Runnable)的进程。
  • 不可中断状态：是指正处于内核态关键流程中的进程，并且这些流程是不可打断的。比如最常见的是等待硬件设备 I/O 相应，可就是 ps 命令看到的 D 状态 (Uninterruptible Sleep，也称为 Disk Sleep)的进程。

当一个进程向磁盘读写数据的时候，为了保证数据的一致性，在磁盘得到回复前，他是不能被其他进程或者中断打断的，这个时候的进程就处于不可中断状态。如果此时的进程被打断了，就容易出现磁盘数据与进程数据不一致的问题。
当平均负载为2时，意味着什么呢？

  • 在只有2个CPU的系统上，意味着所有的CPU都刚好被占用
  • 在4个CPU的系统上，意味着CPU有50%的空闲

  • 在只有1个CPU的系统上，意味着有一半的进程竞争不到CPU

    3、平均负载为多少时合理

    首先，平均负载最理想的情况是等于CPU个数，可以先通过top命令或者从文件 /proc/cpuinfo中读取，比如：

    $ grep 'model name' /proc/cpuinfo | wc -l
2

    获取CPU个数后，当平均负载比CPU个数还大时，系统已经出现了过载。
    而平均负载有三个时间段的值，是给我们提供了，分析系统负载趋势的数据来源。
    假设，在一个单CPU的系统上，看到平均负载为 1.73，0.60，7.98，那么说明在过去 1 分钟内，系统有 73% 的超载，而在 15 分钟内，有 698% 的超载，从整体趋势来看，系统的负载在降低。
    一般当平均负载高于CPU数量 70% 的时候，就应该分析排查负载高的问题了。
    最好的方法，还是监控系统的平均负载，通过更多的历史数据，判断负载的变化趋势。

    4、平均负载与CPU使用率

    平均负载指的是，单位时间内，处于可运行状态和不可中断状态的进程数。
    所以，它不仅包括了正在使用CPU的进程，还包括 等待CPU 和 等待I/O 的进程。
    而CPU使用率，是单位时间内CPU繁忙情况的统计，跟平均负载并不一定完全对应，如：

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

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

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

    5、Demo

    1、准备

    apt install stress sysstat

    stress 是一个 Linux 系统压力测试工具，这里我们用作异常进程模拟平均负载升高的场景。
    sysstat 包含了常用的 Linux 性能工具，用来监控和分析系统的性能。我们的案例会用到这个包的两个命令 mpstat 和 pidstat。

  • mpstat 是一个常用的多核 CPU 性能分析工具，用来实时查看每个 CPU 的性能指标，以及所有 CPU 的平均指标。

  • pidstat 是一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。

    2、场景一：CPU密集型进程

    首先，我们在第一个终端运行 stress 命令，模拟一个 CPU 使用率 100% 的场景：
    stress --cpu 1 --timeout 600
    image.png
    接着，在第二个终端运行 uptime 查看平均负载的变化情况：
    # -d 参数表示高亮显示变化的区域
$ watch -d uptime
    image.png
    1分钟的平均负载会慢慢增加到1.0,
    最后，在第三个终端运行 mpstat 查看 CPU 使用率的变化情况：
    # -P ALL 表示监控所有CPU，后面数字5表示间隔5秒后输出一组数据
$ mpstat -P ALL 5
    image.png
    可以看到，有一个CPU的使用率为100%，而他的iowait是 0。这说明，平均负载升高正是由于 CPU 使用率为 100%。
    可以通过 pidstat来查询哪个进程导致CPU的使用率是 100% 。
    # 间隔5秒后输出一组数据
$ pidstat -u 5 1
    image.png
    可以明显看出 ，stress 进程的 CPU 使用率是 100%。

    3、场景二：I/O密集型进程

    首先还是运行 stress 命令，但这次模拟 I/O 压力，即不停地执行 sync：
    stress -i 1 --timeout 600
    因为该命令是sync()系统调用，他的作用是刷新缓冲区内存到磁盘中。如果是新的虚拟机的话，缓存区比较小，无法产生大的io压力，因此，只能看到CPU使用率升高。
    这里可以使用stree-ng，—hdd 标识读写临时文件
    stress-ng -i 1 --hdd 1 --timeout 600
    还是在第二个终端运行 uptime 查看平均负载的变化情况：
    $ watch -d uptime
..., load average: 1.06, 0.58, 0.37
    然后，第三个终端运行 mpstat 查看 CPU 使用率的变化情况： ```bash

显示所有CPU的指标，并在间隔5秒输出一组数据

$ mpstat -P ALL 5 Linux 4.15.0 (ubuntu) 09/22/18 x86_64 (2 CPU) 13:41:28 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 13:41:33 all 0.21 0.00 12.07 32.67 0.00 0.21 0.00 0.00 0.00 54.84 13:41:33 0 0.43 0.00 23.87 67.53 0.00 0.43 0.00 0.00 0.00 7.74 13:41:33 1 0.00 0.00 0.81 0.20 0.00 0.00 0.00 0.00 0.00 98.99


可以看到，1分钟的负载慢慢增加到1.06，其中一个系统的CPU使用率升到到了23.87，而iowait 高达 67.53%，这说明，平均负载的升高是由于iowait的升高。<br />通过pidstat来查询，哪个进程导致iowait这么高。
```bash

# 间隔5秒后输出一组数据，-u表示CPU指标
$ pidstat -u 5 1
Linux 4.15.0 (ubuntu)     09/22/18     _x86_64_    (2 CPU)
13:42:08      UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
13:42:13        0       104    0.00    3.39    0.00    0.00    3.39     1  kworker/1:1H
13:42:13        0       109    0.00    0.40    0.00    0.00    0.40     0  kworker/0:1H
13:42:13        0      2997    2.00   35.53    0.00    3.99   37.52     1  stress
13:42:13        0      3057    0.00    0.40    0.00    0.00    0.40     0  pidstat

可以发现，还是stress进程导致的。

4、大量进程场景

使用 stress 模拟 8个进程：

stress -c 8 --timeout 600

然后查看平均负载，我们有2个cpu，明显比8个进程少的多，因此，系统的CPU处于严重过载状态，平均负载高达7.61。

$ uptime
06:01:45 up  4:29,  4 users,  load average: 7.61, 3.79, 1.85

接着再运行 pidstat 来看一下进程的情况：
image.png
可以看出，8个进程都在争抢2个CPU，每个进程等到CPU的时间（%wait列）高达75%。这些超出CPU计算能力的进程，最终导致CPU过载。