关于linux系统CPU篇--->平均负载

1.什么是平均负载?(load average)

       平均负载是指单位时间内平均活跃进程数,包括可运行状态的进程数,以及不可中断状态的进程(如等待IO,等待硬件设备响应)

2.如何查看平均负载?

       使用top,uptime查看,分别显示过去1分钟,5分钟,15分钟的平均负载

3.平均负载的性能指标?

   (1).平均负载等于逻辑CPU个数,说明每个CPU都被充分利用

   (2).当平均负载超过CPU个数70%,说明负载比较高

   (3).如果1分钟,5分钟,15分钟的负载相差不大,或者基本相同,说明系统负载很平稳

   (4).如果1分钟负载远大于15分钟,说明系统负载在逐渐升高

   (5).如果1分钟负载远小于15分钟,说明系统负载在逐渐降低

4.平均负载高的场景?

  (1).CPU密集型进程,导致平均负载和CPU使用率比较高

  (2).IO密集型进程,等待IO会导致平均负载升高,但是CPU使用率不一定高

  (3).等待CPU的进程调度也会导致平均负载升高,此时CPU使用率也高

  (4).使用mpstat,pidstat可以分析负载来源

5.案例演示:

 (1).案例准备:

     1.Linux环境,ubantu 18.04,机器配置:2cpu,8GB内存,预先安装stress和sysstat,如 apt install stress sysstat

        stress是linux系统的压力测试工具,这里我们用作异常进程模拟平均负载升高的场景

       而sysstat包含了常用的linux性能工具,用来监控和分析系统的性能。我们的案例会用到这个包的两个命令mpstat和pidstat

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

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

    此外,每个场景都需要你开三个终端,登录到同一台linux机器中

    如果上面的要求都完成了,可以先用uptime 命令,看一下测试前的平均负载情况:

    uptime

    load average: 0.11, 0.15, 0.09

 1.场景1:CPU密集型进程

    首先,我们在第一个终端运行stress命令,模拟一个cpu使用率100%的场景:

    stress --cpu 1 --timeout 600

    接着,在第二个终端运行uptime查看平均负载的变化情况:

    # -d 参数表示高亮显示变化的区域

   $ watch -d uptime

   load average: 1.00, 0.75, 0.39

   最后,在第三个终端运行mpstat查看cpu使用率的变化情况:

   # -P ALL 表示监控所有 CPU,后面数字 5 表示间隔 5 秒后输出一组数据

  $ mpstat -P ALL 5

   Linux 4.15.0 (ubuntu) 09/22/18 _x86_64_ (2 CPU)
  13:30:06 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
  13:30:11 all 50.05 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 49.95
  13:30:11 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
  13:30:11 1 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

  在终端2中可以看到1分钟的平均负载会慢慢增加到1,而从终端三中还可以看到,正好有一个CPU的使用率为100%,但它的iowait

  只有0。这说明,平均负载的升高正是由于CPU使用率为100%。

  那么,到底是哪个进程导致了CPU使用率为100%呢?可以用pidstat 来查询:

  # 间隔 5 秒后输出一组数据
  $ pidstat -u 5 1
  13:37:07 UID PID %usr %system %guest %wait %CPU CPU Command
  13:37:12 0 2962 100.00 0.00 0.00 0.00 100.00 1 stress

  从这里可以看出,stress进程的CPU使用率为100%。

2.场景二:I/O密集型进程:

  首先还是运行stress命令,但这次模拟IO压力,即不停的执行sync:

  stress -i 1 --timeout 600

  还是在第二个终端运行uptime查看平均负载的变化情况:

     watch -d uptime
     load average: 1.06, 0.58, 0.37

  然后,在第三个终端运行mpstat查看CPU使用率的变化情况:

# 显示所有 CPU 的指标,并在间隔 5 秒输出一组数据
$ mpstat -P ALL 5 1
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的系统CPU使用率升高到了23.87,而iowait高达67.53%。这说明,平均负载的升高

正是由于iowait的升高。

 那么,到底是哪个进程导致了iowait的升高呢?我们还是用pidstat来查询:

# 间隔 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进程导致的。

3.场景三:大量进程的场景:

   当系统中运行进程超出CPU运算能力时,就会出现等待CPU的进程。

   比如,我们还是使用stress,但这次是模拟的8个进程:

    stress -c 8 --timeout 600

   由于系统只有2个CPU,明显比8个进程少得多,因而,系统的CPU处于严重过载状态,平均负载高达7.97:

   uptime

..., load average: 7.97, 5.93, 3.02

   接着再运行pidstat来看一下进程的情况:

# 间隔 5 秒后输出一组数据
$ pidstat -u 5 1
14:23:25 UID PID %usr %system %guest %wait %CPU CPU Command
14:23:30 0 3190 25.00 0.00 0.00 74.80 25.00 0 stress
14:23:30 0 3191 25.00 0.00 0.00 75.20 25.00 0 stress
14:23:30 0 3192 25.00 0.00 0.00 74.80 25.00 1 stress
14:23:30 0 3193 25.00 0.00 0.00 75.00 25.00 1 stress
14:23:30 0 3194 24.80 0.00 0.00 74.60 24.80 0 stress
14:23:30 0 3195 24.80 0.00 0.00 75.00 24.80 0 stress
14:23:30 0 3196 24.80 0.00 0.00 74.60 24.80 1 stress
14:23:30 0 3197 24.80 0.00 0.00 74.80 24.80 1 stress
14:23:30 0 3200 0.00 0.20 0.00 0.20 0.20 0 pidstat

可以看出,8个进程在争抢2个CPU,每个进程等待CPU的时间(也就是代码块中的%wait列)高达75%。

这些超出CPU计算能力的进程,最终导致CPU过载。

 

posted @ 2019-03-30 22:41  maxwell11  阅读(1137)  评论(0编辑  收藏  举报