性能分析之Linux系统平均负载案例分析

2019-01-18   出处: 7DGroup  作/译者:左泽位

前言

在上文性能基础之理解Linux系统平均负载和CPU使用率,我们详细介绍了 Linux 系统平均负载的相关概念,本文我们来做几个案例分析,以便于加深理解。

准备工作

测试环境

  • 操作系统:CentOS 7.2 双核

  • 监控工具:iotop、htop、top、uptime、sysstat

  • 压测工具:stress


 
  1. # 获得物理cpu核心的数量

  2. [zzw@7dgroup2 ~]$ lscpu -p | egrep -v '^#' | wc -l

  3. 2

  4. # 获取逻辑cpu数量(包括超线程逻辑cpu数量)

  5. [zzw@7dgroup2 ~]$ lscpu -p | egrep -v '^#' | sort -u -t, -k 2,4 | wc -l

  6. 1

工具介绍

  • iotop 是一个用来监视磁盘 I/O 使用状况的 top 类工具

  • htop 是一款运行于 Linux 系统监控与进程管理软件,用于取代 Linux 下传统的 top。与 top 只提供最消耗资源的进程列表不同,htop 提供所有进程的列表,并且使用彩色标识出处理器、swap 和内存状态。

  • stress 是一个 Linux 系统压力测试工具,一个 Posix 系统下生成Cpu/Menory/IO/Disk 负载的工具。

  • sysstat 包含了常用的 Linux 性能工具,用来监控和分析系统命令。

工具安装


 
  1. # 安装stress

  2. sudo yum install -y epel-release

  3. sudo yum install -y stress


  4. # 安装iotop

  5. sudo yum install -y iotop


  6. # 安装htop

  7. sudo yum install -y htop


  8. # 安装sysstat

  9. sudo yum install -y sysstat  

其它工作

我们打开五个终端,登录到同一台 Linux 机器中。

  • 终端一:stress 模拟 Linux 压测场景

  • 终端二:top 监控进程状况

  • 终端三:iotop 监控进程 I/O 使用状况

  • 终端四:htop 监控进程详细状况

  • 终端五:mpstat 监控系统 iowait 详细状况

案例分析

上面所有准备工作都已经完成了,我们首先使用 uptime 命令看下当前 Linux 的平均负载情况


 
  1. [zzw@7dgroup2 ~]$ uptime

  2. 20:12:34 up 148 days,  3:09,  7 users,  load average: 0.06, 0.10, 0.13

场景一:CPU密集型进程

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


 
  1. # 模拟一个CPU使用率100%的场景。

  2. [zzw@7dgroup2 ~]$ stress --cpu 1 --timeout 600

  3. stress: info: [2395] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd

在终端二查看当前 CPU 使用率及平均负载情况,我们可以看到1分钟的平均负载已经慢慢增加到 1.11,而其中一个CPU1 User使用率已到达 72%。 


 在终端五我们发现系统的 iowait 几乎为 0。这说明,平均负载的升高正是由于 CPU User使用率升高导致的。这个罪魁祸首正是 PID 为 9717 的 stress 进程。 

在终端四上通过 htop 我们也可以很直观了解当前的负载情况,此处我们看到 CPU User使用率颜色是绿色偏高。

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

我们继续在终端一运行 stress 命令,模拟 I/O 压力,即不停的执行 sync

	
 
  1. # 模拟 I/O 压力,不停的执行 sync

  2. [zzw@7dgroup2 ~]$ stress -i 1 --timeout 600

  3. stress: info: [11041] dispatching hogs: 0 cpu, 1 io, 0 vm, 0 hdd

在终端二查看当前 CPU 使用率及平均负载情况,我们可以看到1分钟的平均负载已经慢慢增加到 1.25,而CPU0 System使用率为 68%

在终端五,我们发现两个CPU 都出现了 iowait。这说明,系统平均负载升高是由于 iowait 升高造成的。 

那么到底是哪个进程?在终端三上我们通过 iotop 发现有两个进程在大量执行 IO 写操作,结合 top S列(进程状态代码)使用情况(R和D,即可运行状态和不可中断状态)我们可以发现还是 PID 为 19241 的 stress 进程引起的。

如下图,当我们停止 stress 进程后的状况。

通过终端四的 htop 我们也可以很直观了解当前的负载情况,此处我们看到 CPU 使用率颜色是红色偏高。

场景三:大量进程

当系统中运行的进程数超过 CPU 运行能力时,就会出现等待 CPU 的进程。此处,我们还是使用 stress 模拟 4 个进程。

	
 
  1. [zzw@7dgroup2 ~]$ stress -c 4 --timeout 600

  2. stress: info: [13473] dispatching hogs: 4 cpu, 0 io, 0 vm, 0 hdd

由于系统只有 2 个 CPU,明显比 4 个进程要少得多,因此系统 CPU 处于严重过载状态,平均负载高达4.30

进一步查看运行队列的长度(等待运行的进程数),可以看出,stress 进程们在疯狂的争夺 2 个CPU,这就导致出现运行队列过大,这些超出 CPU 计算能力的进程,最终导致系统过载。

以下是使用 vmstat 命令。

在终端四上通过 htop 我们也可以很直观了解当前的负载情况,此处我们看到 CPU User使用率颜色是绿色偏高。

小结

平均负载提供了一个快速查看系统整体性能的手段,反映了系统的整体负载状况。但并不能跟CPU使用率并不一定完全对应。比如:

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

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

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

另外,htop 根据不同类型的负载加以颜色区别(F2可以自定义)。比如 CPU 密集应用,它的负载颜色是绿色偏高,iowait 的操作,它的颜色是红色偏高。

最后附一张 7DGroup 的经典 linux 性能分析思路图:

简单概况,即操作系统(CPU/IO/Mem/Net)->进程->线程->堆栈->代码,如果 CPU 和 I/O 同时出现高的情况,先看 I/O。


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
451° /4517 人阅读/0 条评论 发表评论

登录 后发表评论
最新文章