iostat - dm-0设备显示的延迟比sdX高得多。
我们正在vmware vSphere5.5之上运行linux (CentOS5.x)VM。我正在使用iostat (特别是等待列)监视磁盘延迟，但我注意到设备映射器/ LVM与支持LVM的“物理”磁盘之间的奇怪结果。
下面是我们的一个相当活跃的vm上iostat -x 5的一组输出。vm有两个磁盘，其中一个分区是/boot，sdb是我们的主磁盘，带有/在sdb2上。iostat显示用于等待sdb2设备(支持volgroup / dm-0的唯一设备/分区)的20-40 my延迟，而对于dm-0的iostat显示100+ms等待。
我的问题是:就系统所看到的真实延迟而言，哪一项统计数据是“正确的”？它是看到了用于“物理”磁盘sdb的~20 Is，还是确实看到了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更新:我做了一些进一步的阅读，包括以下基因答案中的链接。我知道有很多变量涉及到(虚拟化、块文件系统等)，但根据我们供应商+VMware的最佳实践，这部分变量似乎是有序的，而且性能实际上非常好。我真的只是从“VM”的角度来看这个问题。
在这一点上，我怀疑我们的分区+ 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的边界，与标准512 b扇区大小。看起来，当您将LVM应用于整个磁盘时，LVM能够自动对齐，但是由于我们首先将磁盘划分出来，然后使我们的即/dev/sdb2 2分区成为LVM要使用的物理设备，在这种情况下，我不确定它是否能够计算偏移量。按照http://linux.die.net/man/5/lvm.conf，参数data_alignment_offset_detection：“如果设置为1，并且内核为物理卷在sysfs中提供拓扑信息，则物理卷的对齐数据区域的开始将由在sysfs中公开的alignment_offset移动。”这是Centos5，我没有在sysfs中看到任何这些信息，只有在我们的Centos6和更新的vm上，所以它可能无法在物理卷上正确地对齐。
我在VM分区对齐的http://www.netapp.com/us/system/pdf-reader.aspx?m=tr-3747.pdf&cc=us上找到了这个netapp白皮书--具体来说，在第29页4.5节中有很好的信息，关于正确划分VM以便与LVM正确地对齐。我将遵循这一点，这样我们的新vm就正确地对齐了。
这似乎会导致这种行为，有更多知识/经验的人能证实这一点吗？
回答 1
Server Fault用户
发布于 2014-10-04 04:22:47
因为虚拟化涉及到了，所以没有简单的答案。您的虚拟磁盘位于文件系统的顶部，位于向虚拟来宾提供的块设备之上，虚拟来宾有自己的驱动程序，向LVM呈现块设备。我不知道这是否一定会导致如此巨大的差异，但这可能是可能的。
除此之外..。
LVM增加了开销，因此会有差异。如果您的LVM和块设备没有正确地对齐，这也可能是一个因素。
对齐不是一个简单的主题，可以在这样的设置中讨论。我所能做的就是向你推荐几份文件，也许你会在其中找到更多的答案：
https://serverfault.com/questions/633448
复制相似问题
腾讯云开发者
