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

前端之家收集整理的这篇文章主要介绍了linux – iostat – dm-0设备显示比sdX高得多的延迟前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我们在vmware vsphere 5.5之上运行 linux(Centos 5.x)VM.我正在使用iostat监控磁盘延迟,特别是await列,但我注意到设备映射器/ LVM与支持LVM的“物理”磁盘的奇怪结果.

下面是iostat -x 5的一组输出,位于我们相当活跃的VM上.有问题的vm有两个磁盘,sda有1个分区是/ boot,而sdb是我们的主磁盘,带有/ on sdb2.虽然iostat为sdb2设备(支持我的volgroup / dm-0的唯一设备/分区)显示约20-40ms的延迟,但dm-0的iostat显示100 ms等待.

我的问题是:在这里,哪个统计数据“正确”,就系统看到的实际延迟而言?它是否看到“物理”磁盘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的最佳实践,它的这一部分似乎是分类的,而且性能实际上非常好.我真的只是从“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整除,因此您可以使用标准的512b扇区大小在4kb边界上对齐.看起来LVM能够在将其应用到整个磁盘时自动对齐,但由于我们首先将磁盘分区,然后使我们的ie / 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分区对齐http://www.netapp.com/us/system/pdf-reader.aspx?m=tr-3747.pdf&cc=us上找到了这个netapp白皮书
具体来说,第25页第4.5节中有关于正确分区VM以便与LVM正确对齐的信息.我会遵循这一点,所以我们的新vm正确对齐.

这似乎可能导致这种行为,任何有更多知识/经验的人都可以证实这一点吗?

解决方法

由于涉及虚拟化,因此没有简单的答案.您有一个位于文件系统顶部的虚拟磁盘,该文件系统位于提供给虚拟客户机的块设备之上,该虚拟客户机具有自己的驱动程序,向LVM提供块设备.我不确定这是否一定会造成如此巨大的差异,但这可能是可能的.

除此之外…

LVM增加了开销,因此会有所不同.如果您的LVM和块设备未正确对齐,这也可能是一个影响因素.

对齐不是一个简单的主题,可以在这样的设置中涵盖.我能做的最好的就是向您介绍几个文档,也许您会在其中找到更多答案:

> http://people.redhat.com/msnitzer/docs/io-limits.txt
> http://www.techforce.com.br/news/linux_blog/lvm_raid_xfs_ext3_tuning_for_small_files_parallel_i_o_on_debian#.VC90aufPfto

猜你在找的Linux相关文章