一、前言
在上文性能基础之理解Linux系统平均负载和CPU使用率中，我们详细介绍了 Linux 系统平均负载的相关概念，本文我们来做几个案例分析，以达到加深理解。
二、准备工作
1、测试环境
- 操作系统：CentOS 7.2 双核
- 监控工具：iotop、htop、top、uptime、sysstat
- 压测工具：stress
# 获得物理cpu核心的数量
[zzw@7dgroup2 ~]$ lscpu -p | egrep -v '^#' | wc -l
2
# 获取逻辑cpu数量(包括超线程逻辑cpu数量)
[zzw@7dgroup2 ~]$ lscpu -p | egrep -v '^#' | sort -u -t, -k 2,4 | wc -l
1
2、工具介绍
- iotop 是一个用来监视磁盘 I/O 使用状况的 top 类工具
- htop 是一款运行于 Linux 系统监控与进程管理软件，用于取代 Linux 下传统的 top。与 top 只提供最消耗资源的进程列表不同，htop 提供所有进程的列表，并且使用彩色标识出处理器、swap 和内存状态。
- stress 是一个 Linux 系统压力测试工具，一个 Posix 系统下生成Cpu/Menory/IO/Disk 负载的工具。
- sysstat 包含了常用的 Linux 性能工具，用来监控和分析系统命令。
3、工具安装
# 安装stress
sudo yum install -y epel-release
sudo yum install -y stress
# 安装iotop
sudo yum install -y iotop
# 安装htop
sudo yum install -y htop
# 安装sysstat
sudo yum install -y sysstat
4、其它工作
我们打开五个终端，登录到同一台 Linux 机器中。
- 终端一：stress 模拟 Linux 压测场景
- 终端二：top 监控进程状况
- 终端三：iotop 监控进程 I/O 使用状况
- 终端四：htop 监控进程详细状况
- 终端五：mpstat 监控系统 iowait 详细状况
三、案例分析
上面所有准备工作都已经完成了，我们首先使用 uptime 命令看下当前 Linux 的平均负载情况
[zzw@7dgroup2 ~]$ uptime
20:12:34 up 148 days, 3:09, 7 users, load average: 0.06, 0.10, 0.13
1、场景一：CPU密集型进程
首先，我们在终端一运行 stress 命令，模拟一个 CPU 使用率 100% 的场景。
# 模拟一个CPU使用率100%的场景。
[zzw@7dgroup2 ~]$ stress --cpu 1 --timeout 600
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使用率颜色是绿色偏高。
2、场景二：I/O 密集型进程场景
我们继续在终端一运行 stress 命令，模拟 I/O 压力，即不停的执行 sync
# 模拟 I/O 压力，不停的执行 sync
[zzw@7dgroup2 ~]$ stress -i 1 --timeout 600
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 使用率颜色是红色偏高。
3、场景三：大量进程
当系统中运行的进程数超过 CPU 运行能力时，就会出现等待 CPU 的进程。此处，我们还是使用 stress 模拟 4 个进程。
[zzw@7dgroup2 ~]$ stress -c 4 --timeout 600
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 的操作，它的颜色是红色偏高。
最后附一张经典性能分析思路图：
简单概况,即操作系统（CPU/IO/Mem/Net)->进程->线程->堆栈->代码，如果 CPU 和 I/O 同时出现高的情况，先看 I/O。
