在同一台机器上的两个磁盘的戏剧性磁盘I / O性能差异

通过Citrix Xen虚拟化的小型机器(1核,1 GB RAM,CentOs 6.3)具有3个大小完全不同的虚拟磁盘。

> cat /etc/fstab (snippet) ... /dev/mapper/vg_stagingnfs-lv_root / ext4 defaults 1 1 # on /dev/xvda /dev/disk/by-uuid/8048fd86-3aa3-4cdd-92fe-c19cc97d3c2e /opt/xxx/data/nexus ext4 defaults 0 0 /dev/disk/by-uuid/58f16c69-786e-47d0-93ae-d57fb0cbd2a9 /opt/xxx/data/nfs ext4 defaults 0 0 > mount (snippet) ... /dev/mapper/vg_stagingnfs-lv_root on / type ext4 (rw) /dev/xvdb1 on /opt/xxx/data/nexus type ext4 (rw) /dev/xvdc1 on /opt/xxx/data/nfs type ext4 (rw) > df -h (snippet) ... /dev/mapper/vg_stagingnfs-lv_root 5.5G 3.1G 2.2G 59% / /dev/xvdb1 2.0T 60G 1.9T 4% /opt/xxx/data/nexus /dev/xvdc1 729G 144G 548G 21% /opt/xxx/data/nfs 

Device /dev/xvda是一个由“4-Disk-Raid5”支持的“存储库”中的虚拟磁盘。 设备/dev/xvd{b|c}是另一个“存储库”中由另一个4-Disk-Raid5支持的虚拟磁盘。 磁盘性能之间(让我们保持简单) xvdaxvdb 显着不同

 > dd if=/dev/zero of=/root/outfile bs=1024k count=1000 1048576000 bytes (1.0 GB) copied, 8.61225 s, 122 MB/s > dd if=/dev/zero of=/opt/xxx/data/nexus/outfile bs=1024k count=1000 1048576000 bytes (1.0 GB) copied, 86.241 s, 12.2 MB/s 

我还没有发现任何明显的解释通过顶部,顶部,iotop或iostat的差异。 在这两个dd-ing中,我注意到3个主要命令导致加载:dd,flush-xxx和jdb2 / xvdbxxx。 主要types的负载是%sy和%wa。 在xvda关系中使用dd时,%sy:%wa似乎大概是20%:80%,而在xvdb它几乎看起来像是0%:100%。

现在最大的问题是:WTF? 我正在想出如何进一步追踪根本原因。 任何想法如何得到这个底部?

您的帮助是高度赞赏!

我会添加一些额外的信息:

  • 这两个存储库都是LVM支持的
  • 对Xen主机来说都是本地的
  • 奇怪的是:更快的存储库包含> 20个其他虚拟机(以及该虚拟机的xvda )的虚拟磁盘; 磁盘xvdb / xvdc是较慢存储库中的唯一磁盘,只能连接到此虚拟机。 无论如何,我另外创build了第三个虚拟磁盘caching存储库,并将其附加到不同的VM – 相同的效果…

在Xen主机上收集的信息(主要是查找坏盘的证据):

 # xe sr-list (snippet) ... uuid ( RO) : 88decbcc-a88c-b368-38dd-dc11bfa723f6 name-label ( RW): Local storage 2 on xen-build2 name-description ( RW): RAID5 4x1TB 7.200 rpm MDL Disks # aka the too slow one host ( RO): xen-build2 type ( RO): lvm content-type ( RO): user uuid ( RO) : b4bae2a7-02fd-f146-fd95-51f573c9b27d name-label ( RW): Local storage name-description ( RW): # aka the reasonably fast one host ( RO): xen-build2 type ( RO): lvm content-type ( RO): user # vgscan -v (snippet) Wiping cache of LVM-capable devices Wiping internal VG cache Reading all physical volumes. This may take a while... Finding all volume groups Finding volume group "VG_XenStorage-88decbcc-a88c-b368-38dd-dc11bfa723f6" Found volume group "VG_XenStorage-88decbcc-a88c-b368-38dd-dc11bfa723f6" using metadata type lvm2 Finding volume group "VG_XenStorage-b4bae2a7-02fd-f146-fd95-51f573c9b27d" Found volume group "VG_XenStorage-b4bae2a7-02fd-f146-fd95-51f573c9b27d" using metadata type lvm2 # lvmdiskscan (snippet) ... /dev/sdb [ 838.33 GB] LVM physical volume # reasonably fast /dev/sdc [ 2.73 TB] LVM physical volume # too slow 3 disks 16 partitions 2 LVM physical volume whole disks 1 LVM physical volume # vgck -v Finding all volume groups Finding volume group "VG_XenStorage-88decbcc-a88c-b368-38dd-dc11bfa723f6" Finding volume group "VG_XenStorage-b4bae2a7-02fd-f146-fd95-51f573c9b27d" # pvck -v (no output) # lvs LV VG Attr LSize Origin Snap% Move Log Copy% Convert MGT VG_XenStorage-88decbcc-a88c-b368-38dd- dc11bfa723f6 -wi-a- 4.00M VHD-2190be94-2e94-4df1-a78e-b2ee1edf2400 VG_XenStorage-88decbcc-a88c-b368-38dd-dc11bfa723f6 -wi-ao 1.76G VHD-b1971dad-60f0-4d3a-a63d-2f3184d74035 VG_XenStorage-88decbcc-a88c-b368-38dd-dc11bfa723f6 -wi-ao 741.45G VHD-f0c7cc8f-1d69-421d-8a57-97b20c32e170 VG_XenStorage-88decbcc-a88c-b368-38dd- dc11bfa723f6 -wi-ao 2.00T MGT VG_XenStorage-b4bae2a7-02fd-f146-fd95- 51f573c9b27d -wi-a- 4.00M VHD-02a0d5b5-a7e5-4163-a2fa-8fd651ed6df3 VG_XenStorage-b4bae2a7-02fd-f146-fd95-51f573c9b27d -wi-ao 20.05G VHD-0911628d-e03a-459a-83f4-f8c699aee619 VG_XenStorage-b4bae2a7-02fd-f146-fd95-51f573c9b27d -wi-ao 50.11G VHD-0950ba89-401d-433f-87bb-8f1ab9407a4b VG_XenStorage-b4bae2a7-02fd-f146-fd95-51f573c9b27d -wi-ao 30.07G VHD-18e93da6-d18d-4c27-8ea6-4fece41c75c1 VG_XenStorage-b4bae2a7-02fd-f146-fd95-51f573c9b27d -wi--- 8.02G VHD-1b5ced06-a788-4e72-9adf-ea648c816e2e VG_XenStorage-b4bae2a7-02fd-f146-fd95-51f573c9b27d -wi--- 256.00M VHD-22fe1662-6b5d-49f5-b729-ec9acd7787ee VG_XenStorage-b4bae2a7-02fd-f146-fd95-51f573c9b27d -wi-ao 120.24G VHD-23cb8155-39c1-45aa-b6a5-bb8a961707b7 VG_XenStorage-b4bae2a7-02fd-f146-fd95-51f573c9b27d -wi-ao 8.02G VHD-25913e86-214f-4b7f-b886-770247c1d716 VG_XenStorage-b4bae2a7-02fd-f146-fd95-51f573c9b27d -wi-ao 10.03G VHD-44c5045c-6432-48cf-85d3-646e46a3d849 VG_XenStorage-b4bae2a7-02fd-f146-fd95-51f573c9b27d -wi--- 20.05G VHD-4d5f779d-51a9-4087-b113-4d99f16d6779 VG_XenStorage-b4bae2a7-02fd-f146-fd95-51f573c9b27d -wi-ao 50.11G VHD-4e4749c7-8de6-4013-87cb-be53ac112f4f VG_XenStorage-b4bae2a7-02fd-f146-fd95-51f573c9b27d -wi-ao 30.07G VHD-503a68d4-182f-450e-8c34-7568f9472668 VG_XenStorage-b4bae2a7-02fd-f146-fd95-51f573c9b27d -wi-ao 20.05G VHD-5dc961e0-beb2-4ce3-b888-b16a26dd77a5 VG_XenStorage-b4bae2a7-02fd-f146-fd95- 51f573c9b27d -wi-ao 50.11G VHD-6d4ee024-789a-46f5-8922-edf15ac415cd VG_XenStorage-b4bae2a7-02fd-f146-fd95-51f573c9b27d -wi-ao 50.11G VHD-7b80f83f-6a0f-4311-8d32-c8f51b547b3d VG_XenStorage-b4bae2a7-02fd-f146-fd95-51f573c9b27d -wi-ao 120.24G VHD-81aa93fa-dbf5-4a4a-ba21-20693508ec4a VG_XenStorage-b4bae2a7-02fd-f146-fd95-51f573c9b27d -wi-ao 10.03G VHD-85cb8e94-fd07-4717-8cca-871f07099fb0 VG_XenStorage-b4bae2a7-02fd-f146-fd95-51f573c9b27d -wi-ao 50.11G VHD-8e8f63c3-ab21-4707-8736-af0b279c9b7e VG_XenStorage-b4bae2a7-02fd-f146-fd95-51f573c9b27d -wi--- 16.00M VHD-965cc67a-5cb9-4d79-8916-047bfd42955d VG_XenStorage-b4bae2a7-02fd-f146-fd95-51f573c9b27d -wi-ao 64.13G VHD-c1abfb8d-12bc-4852-a83f-ccbc6ca488b8 VG_XenStorage-b4bae2a7-02fd-f146-fd95-51f573c9b27d -wi--- 100.20G VHD-d679959b-2749-47e2-9933-e9f008aea248 VG_XenStorage-b4bae2a7-02fd-f146-fd95-51f573c9b27d -wi-ao 75.15G 

包含更多“-v”的AFAICS仍然不会输出指向坏磁盘的任何内容……可以识别坏磁盘的任何其他检查? 谢谢!

由于性能差异很大,假设一个bug(:-))

严重的是,常见的意外悲观化问题会使你减慢10-20%。 性能错误,就像前面提到的垂死的磁盘一样,会使你放慢几个数量级。

作为一名性能工程师,我所看到的大部分都是bug。

–dave

考虑到你有两套不同的RAID套件,可以想象很多可能的性能差异的原因。 仅仅因为这两个存储库都由一个4磁盘的RAID5支持,你不能指望性能是相似的。

可能的原因:

  • 速度较慢或死亡的磁盘
  • 较慢的RAID控制器
  • 文件支持与逻辑卷支持
  • 本地与远程(NFS,iSCSI)
  • 不同的文件系统(如果文件支持)
  • 其他虚拟机使用的一个存储库的I / O性能

我想你应该走出你的虚拟机进一步debugging。

如果这些arrays是networking安装,请确保机器和较慢的arrays之间没有因为某种原因而被限制到〜100mbps。

除此之外,像其他人所说的那样检查硬件故障或争用。