问题1：性能工具版本太低，导致指标不全
解决方案1：
这是使用 CentOS 的同学普遍碰到的问题。在文章中，我的pidstat 输出里有一个 %wait 指标，代表进程等待 CPU 的时间百分比，
这是 systat 11.5.5 版本才引入的新指标，旧版本没有这一项。而 CentOS 软件库里的 sysstat 版本刚好比这个低，所以没有这项指标。
解决方案2
查看proc文件系统，获取自己想要的指标
问题 2：使用 stress 命令，无法模拟 iowait高的场景
1、分析过程：
使用 stress 无法模拟 iowait 升高，但是却看到sys 升高。这是因为案例中 的 stress -i 参数它表示通过系统调用 sync() 来模拟 I/O 的问题，但这种方法实际上并不可靠。
因为 sync() 的本意是刷新内存缓冲区的数据到磁盘中，以确保同步。如果缓冲区内本来就没多少数据，那读写到磁盘中的，的数据也就不多，也就没法产生 I/O 压力。
这一点，在使用 SSD 磁盘的环境中尤为明显，很可能你的iowait总是 0，却单纯因为大量的系统调用，导致了系CPU 使用率 sys 升高。
2、解决方案：
使用 stress-ng 来代替 stress。
$ stress-ng -i 1 --hdd 1 --timeout 600
-i 的含义还是调用 sync，而—hdd 则表示读写临时文件
问题3：无法模拟出 RES 中断的问题
中断在单核（只有一个逻辑 CPU）的机器上当然就没有意义了，因为压根儿就不会发生重调度的情况。
1、过多的线程争抢CPU
根据非自愿上下文的含义，我们都知道，这是过多的线程在争抢 CPU导致的，其实这个结论也可以从另一个角度获得
pidstat -u -t 1 14:24:03 UID TGID TID %usr %system %guest %wait %CPU CPU Command 14:24:04 0 - 2472 0.99 8.91 0.00 77.23 9.90 0 |__sysbench 14:24:04 0 - 2473 0.99 8.91 0.00 68.32 9.90 0 |__sysbench 14:24:04 0 - 2474 0.99 7.92 0.00 75.25 8.91 0 |__sysbench 14:24:04 0 - 2475 2.97 6.93 0.00 70.30 9.90 0 |__sysbench 14:24:04 0 - 2476 2.97 6.93 0.00 68.32 9.90 0 |__sysbench ...
从这个 pidstat 的输出界面，你可以发现，每个 stress 线程的 %wait 高达 70%，而 CPU使用率只有不到 10%。换句话说， stress 线程大部分分时间都消耗在了等待 CPU 上，
这也表明，确实是过多的线程在争抢 CPU。
2、pidstat 中的 %wait 跟 top 中的 iowait% 没有可比性
有些同学会拿 pidstat 中的 %wait 跟 top 中的 iowait% （缩写为 wa）对比，其实这是没有意义的，因为它们是完全不相关的两个指标。
pidstat 中， %wait 表示进程等待 CPU的时间百分比
top 中 ，iowait% 则表示等待 I/O 的 CPU的时间百分比
3、不同版本的 sysbench 运行参数也不是完全一样的
Ubuntu 18.04 sysbench --threads=10 --max-time=300 threads run Ubuntu 16.04 sysbench --num-threads=10 --max-time=300 --test=threads run
问题 4：无法模拟出 I/O 性能瓶颈，以及 I/O 压力过的问题
1、磁盘性能差异
更是因为磁盘的巨大差异。比如，机械磁盘（HDD）、低端固态磁盘（SSD）与高端固态磁盘相比，性能差异可能达到数倍到数十倍
2、磁盘前缀差异
由于我在案例中只查找了 /dev/xvd 和 /dev/sd前缀的磁盘，而没有考虑到使用其他前缀，磁盘（比如 /dev/nvme）的同学。如果你正好用的是其他
前缀，你可能会碰到跟 Vicky 类似的问题，也就是 app启动后又很快退出，变成 exited 状态。
所以，在最新的案例中，我为 app 应用增加了三个选项。
-d 设置要读取的磁盘，默认前缀为 /dev/sd 或者 /dev/xvd 的磁盘。
-s 设置每次读取的数据量大小，单位为字节，默认为67108864（也就是 64MB）。
-c 设置每个子进程读取的次数，默认为 20 次，也就是说，读取 20*64MB 数据后，子进程退出。
docker run --privileged --name=app -itd feisky/app:iowait /app -d /dev/sdb -s 67108864 -c 20
案例运行后，你可以执行 docker logs 查看它的日志正常情况下，你可以看到下面的输出：
docker logs app Reading data from disk /dev/sdb with buffer size 67108864 and count 20
问题 5：性能工具（如 vmstat）输出中，第一行数据跟其他行差别巨大
[root@luoahong ~]# vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 7541212 0 151572 0 0 296 720 90 121 0 3 97 0 0 0 0 0 7541212 0 151576 0 0 0 0 54 108 0 0 100 0 0 0 0 0 7541212 0 151576 0 0 0 0 45 79 0 0 100 0 0 0 0 0 7541212 0 151576 0 0 0 0 54 94 0 1 100 0 0
1、man vmstat
DESCRIPTION vmstat reports information about processes, memory, paging, block IO, traps, disks and cpu activity. The first report produced gives averages since the last reboot. Additional reports give information on a sampling period of length delay. The process and memory reports are instantaneous in either case.
第一行数据是系统启动以来的平均值其他行才是你在运行 vmstat 命令时设置的间隔时间的平均值。另外，进程和内存的报告内容都是即时数数据
学习是一个“从薄到厚再变薄”的过程，我们从细节知识入手开始学习，积累到一定程度，需要整理成一个体系来记忆，这其中还要不断地对这个体系进行细节修补，
有疑问、有反思才可以达到最佳的学习效果。