vm磁盘映射 不能启动_磁盘性能分析

最近又接到一个关于磁盘的问题，所以，把磁盘性能的分析过程整理了一遍。上一篇主要体现分析思路。这一篇介绍一下要用到的工具。

性能指标

IOPS：Input/Output Per Second， 即每秒系统能能处理的I/O请求数量。

TPUT: 吞吐量。

不同的应用场境，对上述两个指标的关注度是不同的。

随机读写频繁的应用，如小文件存储(图片)、数据库，关注随机读写性能，IOPS是关键衡量指标。
顺序读写频繁的应用，如电视台的视频编辑，备份系统，关注连续读写性能。数据吞吐量是关键衡量指标。

由于传统的机械硬盘是旋转圆盘，因此，读写需要操作磁头到达目标磁道和定位扇区。这意味着机械硬盘还有两个物理指标：寻道时间 和 旋转延迟 。

常见磁盘平均物理寻道时间为：

• 7200 转/分的STAT硬盘平均物理寻道时间是9ms，平均旋转延迟大约 4.17ms
• 10000转/分的STAT硬盘平均物理寻道时间是6ms ，平均旋转延迟大约 3ms
• 15000转/分的SAS硬盘平均物理寻道时间是4ms，平均旋转延迟大约 2ms

最大IOPS的理论计算方法 ： IOPS = 1000 ms/ (寻道时间 + 旋转延迟)。忽略数据传输时间。

• 7200 rpm的磁盘IOPS = 1000 / (9 + 4.17) = 76 IOPS
• 10000 rpm的磁盘IOPS = 1000 / (6+ 3) = 111 IOPS
• 15000 rpm的磁盘IOPS = 1000 / (4 + 2) = 166 IOPS

RAID0/RAID5/RAID6的多块磁盘可以并行工作，所以，在这样的硬件条件下， IOPS 相应倍增。假如， 两块15000 rpm 磁盘的话，166 * 2 = 332 IOPS。

上述通过基本原理计算出的 IOPS 是物理设备的下限。 实际运行环境中，随着读写请求的发生位置，队列深度，调度算法的不同，测试出的 IOPS 会更高。

维基上列出了常见硬盘的IOPS （https://en.wikipedia.org/wiki/IOPS），我摘录一些：

SSD达到了惊人的100,000。 见下图

还有一些其它的指标： IO latency 等。

标定

与 CPU 不同，不同环境下，磁盘的性能指标与厂家标称会不一致。因此，在性能分析前，对所在的计算环境进行标定是很有必要的。用于标定的工具是 fio 。

wget http://ftp.tu-chemnitz.de/pub/linux/dag/redhat/el7/en/x86_64/rpmforge/RPMS/fio-2.1.10-1.el7.rf.x86_64.rpm

fio -filename=/dev/sda -direct=1 -iodepth 1 -thread -rw=randrw -rwmixread=70 -ioengine=psync -bs=16k -size=200G -numjobs=30 -runtime=100 -group_reporting -name=mytest -ioscheduler=noop

上述命令，进行随机读写测试。队列深度为1。

VM (long time running) 是 测试用的虚拟机。这台 VM的磁盘性能极低。只有两位数。同一台 ESXi 上的另一台 VM（new build )，磁盘性能很正常。两者的区别在于，前者不是新装，而是一直跑 volume test 。后者是新安装的。

分析工具

• iostat -x 10

最常用的是 iostat 。10 是时间周期，每10秒输出一份统计数据。

在这个统计数据中，被红框标出的是需要关注的数据。

wrqm/s 是 每秒中 merge 的写请求的数量。 一些写请求可以合并成一个写请求发给驱动。上图中，这个数值很小，说明在这10秒里主要是随机写。

r/s / w/s 是 IO 请求数量，也就是 IOPS， 减去 rqm 就是实际到达驱动的 IOPS 。在这台机器上，IOPS 稳定在250左右时， %util 达到 99.75%

%util 表示的是 占用率。它的计算是 Δio_ticks /Δt . 分子是单位时间内 IO 操作占用的时间，分母是单位时间。有可能 IO 操作少，但总的占用时间长，占用率也可以很高。也可能 IO 操作很多，但大部分都 merge 也，而且 总的占用时间少，那么　占用率就低。

await 是 IO 请求排队的时间 ，它基本等于 Q2D （这个指标见下文）。 时间越长，意味着延时越长。也就是 IO latency 指标。

这个工具给出的数据不能孤立的看。需要组合在一起来分析。当我们想了解为什么 await 为什么那么长时，就需要使用下面的工具。

• blktrace

这个命令很强大，不仅仅可以用来分析 DISK IO。我们在这里只用它的 DISK IO 分析能力。

cd /var/VM_ramdisk 首先，进入 RAM 盘，以免记录数据时，对磁盘产生压力，干扰测试结果。

blktrace -d /dev/sda 记录磁盘 /dev/sda 读写执行的数据。按 Ctrl-C 中止，这时，目录下会产生很多文件。文件名为 sda.blktrace.0。一个 CPU 一个文件。

blkparse -i sda -d sda.blktrace.bin 将所有的文件合并为一个binary dump 文件。

btt -i sda.blktrace.bin | more 最后，可以打开这个 dump 文件，查看分析结果。

Q2G → G2I → I2D → D2C 是 IO请求从应用发出，至到达磁盘的全过程。每个阶段代表的是：

Q – 即将生成IO请求
|
G – IO请求生成
|
I – IO请求进入IO Scheduler队列
|
D – IO请求进入driver
|
C – IO请求执行完毕

上面的 AVG 列，显示了每个过程平均花费时间。上面的数据一共记录了 209579 个请求。 Q2C 的平均时间为 36.17ms。

G2I 平均花费了整个周期的 10.21%， I2D 平均花费了整个周期的13.80%， D2C 平均花费了整个周期的 71.92%。

比较好的运行状态是，Q2G, G2I, I2D 都应该只占有很小很小的百分比。而 D2C 占有超过90%。上图表明，当前的IO运行情况不佳。另一个数据 MAX ，也表明，IO 执行的很不平稳，最大值达到 9.04 秒，抖动非常厉害。

• iowatcher

仅仅查看数据进行分析，非常的不直观。工具 iowatcher 可以把 blktrace 采集的信息，转化为图像和动画，方便分析。

• iowatcher -t sda.blktrace.bin -o disk.svg
• iowatcher -t sda.blktrace.bin --movie -o disk.mp4

首先，我们看 VM volume test 的图像和动画：

https://www.zhihu.com/video/1090678939822850048

解读： 从 Device IO 图可以看到，读写是相当分散的，说明这时，VM 产生的主要是随机读写。从吞吐量来看，读写都不高。这也符合随机读写的场境。IOPs 稳定在 290左右。

下面，对比R440 物理机在日常运行时的图像和动画：

https://www.zhihu.com/video/1090679014586380288

解读：从 DISK IO图来看，读的量不大，而且写主要是连续写。其它的指标也都显著好于 VM。

附上DELL R440 的 btt 数据：