探索Linux-平均负载(一)

shanee
625 阅读5分钟

本篇是Linux性能实战笔记

平均负载

我们使用uptime命令来查看平均负载。

一般来说，会由三种场景导致平均负载的升高。一种是存在CPU密集型的进程，一种是存在IO密集型的进程，还有一种是存在大量的进程导致CPU频繁切换。

环境搭建

机器准备

Linux机器准备，我这里准备了一台CentOs的机器。机器是1核心2GB内存的。

压测工具准备

安装stress和sysstat 在CentOS下可以使用如下命令安装stress

sudo yum install stress sysstat
  • mpstat 是一个常用的多核 CPU 性能分析工具，用来实时查看每个 CPU 的性能指标，以及所有 CPU 的平均指标。
  • pidstat 是一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。

模拟开始

查看初始状态

使用uptime命令查看系统初始的负载情况。

uptime

可以得到如下结果。

[jack@VM_31_196_centos ~]$ uptime
 16:44:06 up 126 days, 21:39,  1 user,  load average: 0.01, 0.05, 0.05

1分钟，5分钟，15分钟的平均负载都在5%以内。

CPU密集

在第一个终端，使用stress,模拟一个CPU使用率100%的场景

stress --cpu 1 --timeout 600

这里使用stress命令来对一个CPU造成100%压力，持续时间为600秒。

在第二个终端中，使用uptime来查看系统的负载情况。

watch -d uptime
 16:54:40 up 126 days, 21:49,  3 users,  load average: 2.76, 2.07, 1.05

使用watch命令表示每隔2秒输出一个uptime的结果。可以看到当前1分钟的CPU的使用率已经达到了276%。不过我估计这个值也不是非常准确。还是下面的mpstat来的更加准确一些。

在第三个终端使用mpstat来查看CPU使用的具体情况。

[jack@VM_31_196_centos ~]$ mpstat -P ALL 5
Linux 3.10.0-693.el7.x86_64 (VM_31_196_centos)  09/22/2019      _x86_64_        (1 CPU)

04:49:27 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
04:49:32 PM  all  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
04:49:32 PM    0  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00

mpstat -P ALL 5中-P ALL表示监控所有的CPU，5表示每隔5秒输出一组数据。

从终端三中可以看到序号为0的CPU的使用率是100%，但是iowait确实0。说明平均负载的升高是由于CPU的使用率导致的。

那么如何找到使得平均负载升高的进程呢？可以使用pidstat来找到这个进程。

[jack@VM_31_196_centos ~]$ pidstat -u 5 1
Linux 3.10.0-693.el7.x86_64 (VM_31_196_centos)  09/22/2019      _x86_64_        (1 CPU)

05:01:24 PM   UID       PID    %usr %system  %guest    %CPU   CPU  Command
05:01:29 PM    27      5834    0.20    0.00    0.00    0.20     0  mysqld
05:01:29 PM  1000      8814   99.00    0.00    0.00   99.00     0  stress
05:01:29 PM  1000      8829    0.20    0.00    0.00    0.20     0  watch
05:01:29 PM     0     27330    0.20    0.00    0.00    0.20     0  java
05:01:29 PM     0     28977    0.20    0.00    0.00    0.20     0  barad_agent

可以看到stress占用了99%的CPU资源。

IO密集

首先还是使用stress来模拟IO密集的情况。

stress -i 1 --timeout 600

上面表示不停的进行sync，并且持续600秒的时间。

在第二个终端上面执行uptime。

watch -d uptime

可以看到平均负载也不断升高到了1.56。

使用mpstat来查看各个CPU的情况。

[jack@VM_31_196_centos ~]$ mpstat -P ALL 5
Linux 3.10.0-693.el7.x86_64 (VM_31_196_centos)  09/22/2019      _x86_64_        (1 CPU)

05:04:10 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
05:04:15 PM  all    1.21    0.00   63.31   35.48    0.00    0.00    0.00    0.00    0.00    0.00
05:04:15 PM    0    1.21    0.00   63.31   35.48    0.00    0.00    0.00    0.00    0.00    0.00

可以看到序号为0的CPU的sys为63，而iowait是35，可以认为是iowait过高导致，平均负载上升。

还是使用pidstat命令来查看是哪一个进程导致CPU的平均负载过高？

[jack@VM_31_196_centos ~]$ pidstat -u 5 1
Linux 3.10.0-693.el7.x86_64 (VM_31_196_centos)  09/22/2019      _x86_64_        (1 CPU)
05:04:35 PM   UID       PID    %usr %system  %guest    %CPU   CPU  Command
05:04:40 PM     0       258    0.00    0.20    0.00    0.20     0  jbd2/vda1-8
05:04:40 PM     0       366    0.00    0.40    0.00    0.40     0  kworker/0:1H
05:04:40 PM     0      1642    0.00    0.20    0.00    0.20     0  kworker/u2:2
05:04:40 PM  1000      8829    0.20    0.20    0.00    0.40     0  watch
05:04:40 PM  1000      9300    0.00   65.12    0.00   65.12     0  stress
05:04:40 PM     0     11852    0.20    0.00    0.00    0.20     0  YDService
05:04:40 PM     0     27330    0.00    0.20    0.00    0.20     0  java
05:04:40 PM     0     28978    0.00    0.20    0.00    0.20     0  barad_agent

可以看到还是stress进程导致的。

大量进程的场景

使用stress模拟4个进程，因为当前机器只有一个CPU，所以肯定是大大查过当前CPU所能处理的继承的数量的。

使用pidstat来查看哪个进程占用了大量的CPU资源。

[jack@VM_31_196_centos ~]$ pidstat -u 5 1
Linux 3.10.0-693.el7.x86_64 (VM_31_196_centos)  09/22/2019      _x86_64_        (1 CPU)
05:17:48 PM   UID       PID    %usr %system  %guest    %CPU   CPU  Command
05:17:53 PM     0      7255    0.20    0.00    0.00    0.20     0  dockerd
05:17:53 PM  1000      8829    0.20    0.00    0.00    0.20     0  watch
05:17:53 PM  1000     11248   24.90    0.00    0.00   24.90     0  stress
05:17:53 PM  1000     11249   24.50    0.00    0.00   24.50     0  stress
05:17:53 PM  1000     11250   24.50    0.00    0.00   24.50     0  stress
05:17:53 PM  1000     11251   24.70    0.00    0.00   24.70     0  stress
05:17:53 PM     0     11852    0.00    0.20    0.00    0.20     0  YDService
05:17:53 PM     0     27330    0.20    0.00    0.00    0.20     0  java
05:17:53 PM     0     28978    0.20    0.00    0.00    0.20     0  barad_agent

可以看到4个stress进程占用了所有的CPU资源。不过不知道为什么没有像专栏中存在wait列？

评论区解惑

  1. iowait无法升高的问题，是因为案例中stress使用的是 sync() 系统调用，它的作用是刷新缓冲区内存到磁盘中。对于新安装的虚拟机，缓冲区可能比较小，无法产生大的IO压力，这样大部分就都是系统调用的消耗了。所以，你会看到只有系统CPU使用率升高。解决方法是使用stress的下一代stress-ng，它支持更丰富的选项，比如 stress-ng -i 1 --hdd 1 --timeout 600（--hdd表示读写临时文件）。

  2. pidstat输出中没有%wait的问题，是因为CentOS默认的sysstat稍微有点老，源码或者RPM升级到11.5.5版本以后就可以看到了。而Ubuntu的包一般都比较新，没有这个问题。

  3. mpstat无法观测的问题，案例中是等待5秒后输出1次结果就停止了，更好的做法是持续监控一段时间，比如持续观测20次：mpstat -P ALL 5 20

小结

  1. 平均负载可以代表当前系统总体的负载情况
  2. 平均负载升高的原因可能是存在占用CPU的进程，也可能是IO密集型的进程还可能是大量进程在系统中，使得CPU存在大量的上下文切换导致系统负载升高
  3. 可以使用mpstat，pidstat来排查问题

关于写作

"百天"写作计划下半部。

每周更新一篇碎碎念。

每周三、周六更新一篇尽量全面，详细的文章。

可能时长突破了百天，但是又有什么关系呢？提高写作水平，形成写作的习惯才是最终的目的。

如果这篇文章给你带来了一些帮助，可以动动手指点个赞，顺便关注一波就更好了。

如果上面都没有，那么写下读完之后最想说的话？有效的反馈和你的鼓励是对我最大的帮助。

另外打算把博客给重新捡起来了。欢迎大家来访问吃西瓜。

我是shane。今天是2019年9月22日。"百天"写作计划下半部，53/100。

avatar
文章
阅读
粉丝