Linux-系统负载

Posted by 令德湖周杰伦 on 10-06,2020

一、查看系统负载

可以使用top或者uptime命令来查看。

uptime命令

uptime
结果:20:00:43 up 258 days,  9:45,  1 user,  load average: 0.25, 0.09, 0.06

解释:
20:00:43 当前时间;
up 258 days, 9:45 系统运行的时间;
load average: 0.25, 0.09, 0.06 平均负载情况,依次是过去1min、5min、15min的统计;

二、什么是系统平均负载?

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

可运行状态

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

不可中断状态

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

三、平均负载为多少时合理?

平均负载最理想的情况是等于CPU个数,就是每个CPU上都刚好运行着一个进程,这样每个 CPU 都得到了充分利用。

查询CPU的个数

使用top命令 或者 从文件/proc/cpuinfo中读取

grep 'model name' /proc/cpuinfo 
-> model name	: Intel(R) Xeon(R) Platinum 8269CY CPU @ 2.50GHz
grep 'model name' /proc/cpuinfo | wc -l
-> 1

cpu使用率

是单位时间内CPU繁忙情况的统计,跟平均负载并不一定完全对应,平均负载它不仅包括了正在使用 CPU 的进程,还包括等待 CPU 和等待I/O 的进程。
比如:

  • CPU 密集型进程,使用大量 CPU 会导致平均负载升高,此时这两者是一致的;
  • I/O 密集型进程,等待 I/O 也会导致平均负载升高,但 CPU 使用率不一定很高;
  • 大量等待 CPU 的进程调度也会导致平均负载升高,此时的 CPU 使用率也会比较高。

趋势

如果load average这3个数从左到右在递减,代表负载在升高,反之在降低,也好非常好理解。
当平均负载高于 CPU 数量 70% 的时候,你就应该分析排查负载高的问题了,一旦负载过高,就可能导致进程响应变慢,进而影响服务的正常功能。

四、查询负载升高的原因

使用 stress + uptime + mpstat + pidstat 等命令来模拟和观察负载升高的场景。
注:
stress 是一个 Linux 系统压力测试工具,这里我们用作异常进程模拟平均负载升高的场景。在centos 上安装strees:yum install stress
mpstat 是一个常用的多核 CPU 性能分析工具,用来实时查看每个 CPU 的性能指标,以及所有 CPU 的平均指标。
pidstat 是一个常用的进程性能分析工具,用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。

模拟CPU 密集型进程

第一个终端运行 stress 命令,模拟一个 CPU 使用率 100% 的场景:

//-c, --cpu N  产生 N 个进程,每个进程都反复不停的计算随机数的平方根
stress --cpu 1 --timeout 600 

第二个终端查看平均负载的变化情况:

//-d 参数表示高亮显示变化的区域
watch -d uptime 

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

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

查询是哪个进程导致CPU使用率为100%呢?

//-u:默认的参数,显示各个进程的cpu使用统计
pidstat -u 5 1

结果行command显示为stress

模拟I/O 密集型进程

第一个终端运行stress 命令,但这次模拟 I/O 压力,即不停地执行 sync:

//-i, --io N  产生 N 个进程,每个进程反复调用 sync() 将内存上的内容写到硬盘上
stress -i 1 --timeout 600

其他步骤同上

模拟大量进程的场景

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

stress -c 8 --timeout 600

运行pidstat来看一下进程的情况,可以看出,4个进程在争抢 1 个 CPU,每个进程等待 CPU 的时间(也就是代码块中的%wait 列)高达 75%。这些超出 CPU 计算能力的进程,最终导致 CPU 过载。