0
点赞
收藏
分享

微信扫一扫

浅谈Linux系统平均负载


浅谈Linux系统平均负载_运行时间

 

前言

每次发现系统变慢时,我们通常做的第一件事,就执行top或者uptime命令,来了解系统的负载情况。比如像下面这样,我在命令行里输入了 uptime命令,系统也随即给出了结果。

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

但我想问的是,你真的知道这里每列输出的含义吗?相信你对前面的几列比较熟悉,它们分别是当前时间、系统运行时间以及正在登录用户数.

02:34:03       //当前时间

up 2 days, 20:14     //系统运行时间

1 user          //正在登录用户数

而最后三个数字呢 0.63, 0.83, 0.88,依次则是过去1分钟、5分钟、15分钟的平均负载(Load Average)。

 

uptime含义

有人会说,平均负载不就是单位时间内的CPU使用率吗?上面的0.63,就代表CPU 使用率是63%。其实并不是这样,如果你方便的话,可以通过执行man uptime命令,来了解平均负载的详细解释。

简单来说,平均负载是指单位时间内,系统处于可运行状态和不可中断状态的平均进程数,也就是平均活跃进程数,它和CPU使用率并没有直接关系。这里先解释下可运行状态和不可中断状态这俩词。

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

不可中断状态的进程则是正处于内核态关键流程中的进程,并且这些流程是不可打断的比如最常见的是等待硬件设备的I/O响应,也就是我们在ps命令中看到的D状态(Uninterruptible Sleep,也称为Disk Sleep)的进程

比如,当一个进程向磁盘读写数据时,为了保证数据的一致性,在得到磁盘回复前,它是不能被其他进程或者中断打断的,这个时候的进程就处于不可中断状态。如果此时的进程被打断了,就容易出现磁盘数据与进程数据不一致的问题。

所以,不可中断状态实际上是系统对进程和硬件设备的一种保护机制。

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

既然平均的是活跃进程数,那么最理想的,就是每个CPU上都刚好好运行着一个进程,这样每个 CPU都得到了充分利用。比如当平均负载为2时,意味着什么呢?

・在只有2个CPU的系统上,意味着所有的CPU都刚好被完全占用

・在4个CPU的系统上,意味着CPU有50%的空闲

・而在只有1个CPU的系统中,则意味着有一半的进程竞争不到CPU

 

平均负载为多少时合理

讲完了什么是平均负载,现在我们再回到最开始的例子,不知道你能否判断出,在uptime命令 的结果里,那三个时间段的平均负载数,多大的时候能说明系统负载高?或是多小时候就能说明系统负载很低呢?

我们知道,平均负载最理想的情况是等于CPU个数。所以在评判平均负载时,首先你要知道系统有几个CPU,这可以通过top命令或者从文件/proc/cpuinfo中读取,比如:

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

有了 CPU个数,我们就可以判断出,当平均负载比CPU个数还大的时候,系统已经出现了过载。不过,且慢,新的问题又来了。我们在例子中可以看到,平均负载有三个数值,到底该参考哪一 个呢?

实际上,都要看。三个不同时间间隔的平均值,其实给我们提供了,分析系统负裁趋势的数据来源,让我们能更全面、更立体地目前的负载状况。

打个比方,就像初秋时北京的天气,如果只看中午的温度,你可能以为还在7月份的大夏天呢。但如果你结合了早上、中午、晚上三个时间点的温度来看,基本就可以全方位了解这一天的天气情况了。

同样的,前面说到的CPU的三个负载时间段也是这个道理。

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

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

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

这里我再举个例子,假设我们在一个单CPU系统上看到平均负载为1.73, 0.60, 7.98,那么说 明在过去1分钟内,系统有73%的超载,而在15分钟内,有698 %的超载,从整体趋势来看系统的负载在降低。

那么,在实际生产环境中,平均负载多高时,需要我们重点关注呢?

在我看来,当平均负载高于CPU数量70%的时候,你就应该分析排查负载高的问题了。一旦负载过高,就可能导致进程响应变慢,进而影响服务的正常功能。

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

 

 

平均负载与CPU使用率

现实工作中,我们经常容易把平均负载和CPU使用率混淆,所以在这里,我也做一个区分。可能你会疑惑,既然平均负载代表的是活跃进数,那平均负载高了,不就意味着CPU使用率高吗?

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

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

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

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

 

 

最后做一个详细解释

概念

平均负载指的是单位时间内(1,5,15分钟)系统处于可运行状态不可中断状态的平均进程数,也就是平均活跃进程数

  • 可运行状态: 正在使用CPU或者等待CPU的进程,也就是通过​​ps aux​​看到的状态为R的进程
  • 不可中断状态: 正处于内核关键流程中的进程,并且这些流程是不可被打断的,比如IO响应。也就是通过​​ps aux​​看到的状态为D的进程。

不可中断状态实际上是系统对进程和硬件设备的一种保护机制

既然平均的是活跃进程数,那么最理想的就是每个CPU上正好运行着一个进程,每个进程CPU都得到了充分的利用。

一、uptime 命令

$ uptime
16:33:56 up 69 days, 5:10, 1 user, load average: 0.14, 0.24, 0.29

以上信息的解析如下:

  • 16:33:56 : 当前时间 up 69 days, 5:10 : 系统运行了69天5小时10分 1 user :
  • 当前有1个用户登录了系统load average: 0.14, 0.24, 0.29 :
  • 系统在过去1分钟内,5分钟内,15分钟内的平均负载 load average: 0.14, 0.24, 0.29 :
  • 系统在过去1分钟内,5分钟内,15分钟内的平均负载

平均负载解析

查看逻辑 CPU 核心数:

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

运行结果表示,有 1 个逻辑 CPU 核心。以1个CPU核心为例,假设 CPU 每分钟最多处理100个进程 –

  • load=0,没有进程需要 CPU
  • load=0.5,CPU处理了 50 个进程
  • load=1, CPU 处理了 100 个进程,这时 CPU 已被占满,但系统还是能顺畅运作的
  • load=1.5, CPU 处理了 100 个进程,还有 50 个进程正在排除等着 CPU 处理,这时,CPU 已经超负荷工作了

为了系统顺畅运行,load 值最好不要超过 1.0,这样就没有进程需要等待了,所有进程都能第一时间得到处理。

很显然,1.0 是一个关键值,超过这个值,系统就不在最佳状态了。 一般 0.7 是一个比较理想的值。

另外,load 值的健康状态还跟系统 CPU 核心数相关,如果 CPU 核心数为 2,那么 load 值健康值应该为 2,以此类推。
评价系统的负载一般采用 15 分钟内的那个平均负载值。

举报

相关推荐

0 条评论