阅读 413

Linux系统篇—CPU平均负载介绍与案例假设

「本文已参与好文召集令活动,点击查看:后端、大前端双赛道投稿,2万元奖池等你挑战!

平均负载

通过执行top或者uptime命令,可以了解系统的负载情况,如图所示:

image.png

每列输出的含义:

第一行包括:当前时间、系统运行时间、正在登陆的用户数
image.png

load average:三个数字分别表示 过去1分钟、5分钟、15分钟的平均负载

cpu使用率

CPU 使用率,是单位时间内 CPU 繁忙情况的统计,跟平均负载并不一定完全对应。 比如:

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

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

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

平均负载的含义

平均负载是指单位时间内,系统处于可运行状态不可中断状态的平均进程数,它不仅包括了正在使用 CPU 的进程,还包括等待 CPU 和等待I/O 的进程。也就是平均活跃进程数,它和 CPU 使用率并没有直接关系。

  • 可运行状态的进程
    正在使用 CPU 或者正在等待 CPU 的进程,也就是我们常用ps 命令看到的,处于 R 状态(Running 或 Runnable) 的进程

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

平均负载多少合适

最理想的负载就是每个cpu上都刚好运行一个进程,这样每个cpu都得到了充分利用。所以在评判平均负载时,首先你要知道系统有几个 CPU,可通过以下命令查询

# 关于 grep 和 wc 的用法请查询它们的手册或者网络搜索
grep 'model name' /proc/cpuinfo | wc -l
复制代码

当平均负载为2时,意味着什么呢?

  • 在只有 2 个 CPU 的系统上,意味着所有的 CPU 都刚好被完全占用。
  • 在 4 个 CPU 的系统上,意味着 CPU 有 50% 的空闲。
  • 而在只有 1 个 CPU 的系统中,则意味着有一半的进程竞争不到 CPU。

当平均负载比 CPU 个数还大的时候,系统就已经出现了过载。

load average变化举例说明

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

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

一般情况下,当 平均负载高于 CPU 数量 70% 的时候,就应该分析排查负载高的问题了

但 70% 这个数字并不是绝对的,最推荐的方法,还是把系统的平均负载监控起来,然后根据更多的历史数据,判断负载的变化趋势。当发现负载有明显升高趋势时,比如说负载翻倍了,再去做分析和调查。

平均负载问题排查与案例假设

通过使用iostatmpstatpidstat工具,找出平均负载升高的根源

准备

预先安装 stresssysstat 包,如 apt install stress sysstat

  • stress: 一个 Linux 系统压力测试工具,可以用作异常进程模拟平均负载升高的场景。
  • sysstat: 包含了常用的 Linux 性能工具,用来监控和分析系统的性能。案例会用到这个包的两个命令 mpstatpidstat
    • mpstat 一个常用的多核 CPU 性能分析工具,用来实时查看每个 CPU 的性能指标,以及所有 CPU 的平均指标
    • pidstat 一个常用的进程性能分析工具,用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。

场景一:CPU 密集型进程

  1. 在第一个终端运行 stress --cpu 1 --timeout 600 命令,模拟一个 CPU 使用率 100% 的场景 (不想模拟的可以忽略)
  2. 在第二个终端运行 watch -d uptime 查看平均负载的变化情况 (-d 参数表示高亮显示变化的区域)
  3. 在第三个终端运行 mpstat -P ALL 5 查看 CPU 使用率的变化情况 (-P ALL 表示监控所有 CPU,后面数字 5 表示间隔 5 秒后输出一组数据)

    [2] 可以看到,1 分钟的平均负载会慢慢增加到 1.00,而从 [3] 中还可以看到,正好有一个 CPU 的使用率为 100%,但它的 iowait 只有 0。这说明,平均负载的升高正是由于 CPU 使用率为 100% 。

  4. 使用 pidstat -u 5 1 来查找哪个进程导致了 CPU 使用率为 100% (间隔 5 秒后输出一组数据) image.png
    从这里可以明显看到,stress 进程的 CPU 使用率为 100%。

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

  1. 运行 stress -i 1 --timeout 600 命令,但这次模拟 I/O 压力,即不停地执行 sync
  2. 在第二个终端运行 watch -d uptime 查看平均负载的变化情况 (-d 参数表示高亮显示变化的区域)
  3. 在第三个终端运行 mpstat -P ALL 5 1 查看 CPU 使用率的变化情况 (-P ALL 表示监控所有 CPU,后面数字 5 表示间隔 5 秒后输出一组数据) image.png

    [3] 可以看到,1 分钟的平均负载会慢慢增加到 1.06,其中一个CPU的系统的CPU使用率升高到了 23.87,而 iowait 高达 67.53%。这说明,平均负载的升高是由于 iowait 的升高。

  4. 使用 pidstat -u 5 1 来查找哪个进程导致 iowait 这么高 (间隔 5 秒后输出一组数据) image.png
    可以发现,还是 stress 进程导致的。

场景三:大量进程的场景

  1. 使用stress -c 8 --timeout 600,这次模拟的是 8 个进程(于系统只有 2 个 CPU,系统的 CPU 处于严重过载状态)
    image.png
  2. 在第二个终端运行 mpstat -P ALL 5 1 查看 CPU 使用率的变化情况 (-P ALL 表示监控所有 CPU,后面数字 5 表示间隔 5 秒后输出一组数据) image.png
  3. 运行pidstat -u 5 1 来看一下进程的情况 (间隔 5 秒后输出一组数据)
    image.png

    可以看出,8 个进程在争抢 2 个 CPU, 每个进程等待 CPU 的时间(也就是代码块中的%wait列)高达 75%。 这些超出 CPU 计算能力的进程,最终导致 CPU 过载。

总结

平均负载提供了一个快速查看系统整体性能的手段,反映了整体的负载情况。但只看平均负载本身,我们并不能直接发现到底是哪里出现了瓶颈。

在理解平均负载时,要注意:

  • 平均负载高有可能是 CPU 密集型进程导致的;
  • 平均负载高并不一定代表 CPU 使用率高,还有可能是 I/O 更繁忙了;
  • 当发现负载高的时候,可以使用 mpstatpidstat 等工具,辅助分析负载的来源。

其他

pidstat没有展示%wait

升级systat到 11.5.5版本及以上

# 通过git下载源码
git clone git://github.com/sysstat/sysstat
# 系统配置sysstat
cd  sysstat/
./configure
# 编译和安装
make & make install
# 验证是否安装成功
mpstat -V
# 解决 /usr/bin/mpstat: No such file or directory 
cp pidstat /usr/bin/
cp mpstat /usr/bin/
复制代码

关注+点赞👍收藏❤️不迷路

文章每周持续更新,可以微信搜索「 十分钟学编程 」第一时间阅读和催更,如果这个文章写得还不错,觉得有点东西的话
各位的支持和认可,就是我创作的最大动力,我们下篇文章见!

文章分类
后端