板桥随笔
首发于板桥随笔
磁盘性能分析

磁盘性能分析

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

性能指标

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 (en.wikipedia.org/wiki/I),我摘录一些:

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

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

标定

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

wget ftp.tu-chemnitz.de/pub/

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 数据:

编辑于 2019-03-17

文章被以下专栏收录