原文链接：小polo测试笔记
stress 介绍
Linux 系统压力测试工具，这里通过异常进程模拟平均负载升高的场景
stress 命令行参数的讲解
| 字段 | 含义 |
|---|---|
| -?、–help | 帮助文档 |
| –version、-v | 版本号 |
| -q | 退出 |
| -n | 显示已完成指令的情况 |
| -t N、–timeout N | 运行 N 秒后停止 |
| –backoff N | 等待 N 微秒后开始运行 |
| -c N、–cpu N | 产生 N 个进程 每个进程反复的计算随机数的平方根 模拟 CPU 计算密集型场景 |
| -i N、–io N | 产生 N 个进程 每个进程反复调用 sync() 模拟 I/O 密集型场景 |
| -m N、–vm N | 产生 N 个进程 每个进程不断调用内存分配 malloc() 和内存释放 free() 函数 |
| –vm-bytes B | 指定 malloc() 时内存的字节数，默认256MB |
| –vm-hang N | 指定执行 free() 前等待的秒数 |
| -d N、 --hdd N | 产生 N 个进程 每个进程执行 write() 和 unlink() 的进程 |
| –hdd-bytes B | 每个 hdd worker 写入 B 字节（默认为1GB） |
sysstat 介绍
- 包含了常用的 Linux 性能工具，用来监控和分析系统的性能
- 接下来会用到 mpstat 和 pidstat 两个命令
- 后面用单独一篇详细讲解里面包含的所有命令
mpstat
- 常用的多核 CPU 性能分析工具
- 实时查看每个 CPU 的性能指标以及所有 CPU 的平均指标
pidstat
- 常用的进程性能分析工具
- 实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标
安装
stress 安装
sysstat 安装
示例
1. CPU 密集型进程
第一个终端
在第一个终端运行 stress 命令，模拟一个 CPU 使用率 100% 的场景
stress -c 1 -t 600 
第二个终端
运行 uptime 查看系统平均负载情况，-d 参数表示高亮显示变化的区域
watch -d uptime
可以看到，1 分钟的平均负载会慢慢增加到 1.00
第三个终端
运行 mpstat 查看 CPU 使用率的变化情况
mpstat -P ALL 5
可以看出
- 仅有一个 CPU 的使用率接近 100%，但它的 iowait 只有 0
- 这说明，平均负载的升高正是由于 CPU 使用率为 100%
使用 pidstat 命令
间隔 5 秒后输出一组数据
pidstat -u 5 1
I/O 密集型进程
第一个终端
第二个终端
运行 uptime 查看系统平均负载情况，-d 参数表示高亮显示变化的区域
第三个终端
运行 mpstat 查看 CPU 使用率的变化情况
mpstat -P ALL 5 1
- iowait 无法升高是因为案例中 stress -i 使用的是 sync() 系统调用，它的作用是刷新缓冲区内存到磁盘中
- 对于新安装的虚拟机，缓冲区可能比较小，无法产生大的io压力
- 这样大部分都是系统调用的消耗了
- 所以，只看到系统 CPU 使用率升高
解决办法
使用 stress 的另一个参数 -d
stress --hdd 1 -t 600 --hdd-bytes 4G
模拟超负载运行
这次模拟 8 个进程(决定你机器的核数，这里是针对4核机器来说超了一倍的负载)
stress -c 8 -t 600
可以直接通过 pidstat 来查看进程的情况了，每隔 5s 收集一次，收集 5 次，看平均值
pidstat -u 5 5
可以看到
- 8 个进程在竞争 4 个 CPU
- 每隔进程等待 CPU 的时间（%wait）高达 50%
- 这些超出 CPU 计算能力的进程，导致 CPU 过载
对于平均负载的一个理解和总结
- 平均负载提供了一个快速查看系统整体性能的手段，反映了整的负载情况
- 但只看平均负载本身，我们并不能直接发现到底是哪里出现了瓶颈
- 平均负载过高的分析排查思路
- 有可能是 CPU 即密集型进程导致的
- 平均负载过高不代表 CPU 使用率高，也有可能是 I/O 更密集了
- 当发现平均负载过高时，可以通过 mpstat、pidstat 等工具，辅助分析负载的来源
