☰

iostat - dm-0 设备显示的延迟比 sdX 高得多

tag-icon • tag-icon linux performance monitoring
iostat - dm-0 设备显示的延迟比 sdX 高得多

我们在 vmware vsphere 5.5 上运行 linux (Centos 5.x) VM。我正在使用 iostat 监控磁盘延迟，特别是 await 列，但我注意到设备映射器/LVM 与支持 LVM 的“物理”磁盘的结果很奇怪。

下面是我们其中一个相当活跃的虚拟机上的 iostat -x 5 的一组输出。有问题的虚拟机有两个磁盘，sda 的 1 个分区是 /boot，sdb 是我们的主磁盘，sdb2 上有 /。虽然 iostat 显示 sdb2 设备（支持我的 volgroup / dm-0 的唯一设备/分区）的等待延迟约为 20-40ms，但 dm-0 的 iostat 显示等待时间超过 100 毫秒。

我的问题是：就系统看到的实际延迟而言，哪个统计数据是“正确的”？是看到“物理”磁盘 sdb 显示的 ~20ms，还是看到 dm-0 的 100+ms，可能是由于 LVM 参与时出现的一些对齐/等问题？这很奇怪，因为有时统计数据匹配得很好，而其他时候则相差甚远 - 例如，在下面的 iostat 输出块中，sdb2 显示 419 写入 IOPS，而 dm-0 显示 39k 写入 IOPS。

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.78    0.00    8.42   39.07    0.00   46.73

Device:         rrqm/s   wrqm/s   r/s   w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda1              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb              15.67 39301.00 745.33 419.67 64146.67 317765.33   327.82    53.55   45.89   0.86 100.07
sdb1              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb2             15.67 39301.00 745.33 419.67 64146.67 317765.33   327.82    53.55   45.89   0.86 100.07
dm-0              0.00     0.00 761.33 39720.67 64120.00 317765.33     9.43  4933.92  121.88   0.02 100.07

更新：我做了一些进一步的阅读，包括下面 Gene 的回答中的链接。我知道涉及很多变量（虚拟化、块文件系统等），但根据我们的供应商 + VMware 的最佳实践，这部分似乎已经整理好了，而且性能实际上非常好。我真的只是从“虚拟机内部”的角度来看待这个问题。

就这一点而言，我怀疑我们的分区 + LVM 对齐存在问题：

GNU Parted 1.8.1
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit s
(parted) print

Model: VMware Virtual disk (scsi)
Disk /dev/sdb: 2147483647s
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start     End          Size         Type     File system  Flags
 1      63s       4192964s     4192902s     primary  linux-swap   boot
 2      4192965s  2097151999s  2092959035s  primary               lvm

~]# pvdisplay
  --- Physical volume ---
  PV Name               /dev/sdb2
  VG Name               VolGroup00
  PV Size               998.00 GB / not usable 477.50 KB
  Allocatable           yes (but full)
  PE Size (KByte)       32768
  Total PE              31936
  Free PE               0
  Allocated PE          31936
  PV UUID               tk873g-uSZA-JaWV-R8yD-swXg-lPvM-dgwPQv

读取对齐信息后，看起来您的起始扇区应该能被 8 整除，因此您以 4kb 为边界对齐，扇区大小为标准 512b。看起来 LVM 能够在您将其应用于整个磁盘时自动对齐，但由于我们首先对磁盘进行分区，然后将我们的分区（即 /dev/sdb2 分区）设为 LVM 使用的物理设备，因此我不确定它是否能够在这种情况下计算偏移量。每http://linux.die.net/man/5/lvm.conf，参数 data_alignment_offset_detection：“如果设置为 1，并且您的内核在 sysfs 中为物理卷提供拓扑信息，则物理卷的对齐数据区域的起始将根据 sysfs 中公开的 alignment_offset 进行偏移。”这是 Centos5，我没有在 sysfs 中看到任何公开的信息，仅在我们的 Centos6 和更新的 vm 上，因此它可能无法在物理卷上正确对齐。

我发现这个有关 VM 分区对齐的 netapp 白皮书http://www.netapp.com/us/system/pdf-reader.aspx?m=tr-3747.pdf&cc=us 具体来说，第 4.5 节第 29 页提供了有关正确分区 VM 以便与 LVM 正确对齐的有用信息。我将遵循这些信息，以便我们的新 VM 正确对齐。

这似乎可能会导致这种行为，有更多知识/经验的人可以证实这一点吗？

答案1

由于涉及到虚拟化，所以没有简单的答案。虚拟磁盘位于文件系统之上，文件系统位于呈现给虚拟客户的块设备之上，虚拟客户机有自己的驱动程序，用于向 LVM 呈现块设备。我不确定这是否必然会导致如此巨大的差异，但有可能。

除此之外...

LVM 会增加开销，因此会有差异。如果您的 LVM 和块设备未正确对齐，这也可能是一个促成因素。

对齐并不是一个简单的主题，无法在这样的环境中涵盖。我能做的最好的就是向您推荐几份文件，也许您会在其中找到更多答案：

相关内容