通过 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
设备/dev/xvda是“存储库”内的虚拟磁盘，由 4-Disk-Raid5 提供支持。设备/dev/xvd{b|c}是位于另一个“存储库”内的虚拟磁盘，由另一个 4-Disk-Raid5 提供支持。磁盘性能之间（让我们保持简单）xvda并且xvdb是截然不同：
> 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
我没有发现 top、atop、iotop 或 iostat 有任何明显的差异。在两次 dd-ings 期间，我注意到 3 个主要命令导致负载：dd、flush-xxx 和 jdb2/xvdbxxx。主要负载类型是 %sy 和 %wa。在 dd-ingxvda关系 %sy:%wa 期间看起来大致为 20%:80%，在 dd-ing 期间xvdb看起来几乎为 0%:100%。
现在最大的问题是：WTF？我不知道该如何进一步追查根本原因。有什么办法可以查明真相吗？
非常感谢您的帮助！
我将添加一些额外的信息：
- 两个存储库均由 LVM 支持
- 两者都是 Xen 主机本地的
- 奇怪：更快的存储库包含 20 多个其他虚拟机（以及
xvda此虚拟机）的虚拟磁盘；磁盘xvdb/xvdc是仅有的磁盘位于较慢的存储库中，并且仅连接到此 VM。无论如何，我还在该较慢的存储库上创建了第三个虚拟磁盘，并将其连接到另一个 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 # a.k.a. 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): # a.k.a. 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”仍然没有输出任何指向坏磁盘的内容...还有其他检查可以识别坏磁盘吗？谢谢！
答案1
性能差异如此之大，假设是一个错误(:-))
严肃地说，常见的意外悲观问题将使你的速度减慢 10-20%。性能错误（如前面提到的坏掉的磁盘）将使你的速度减慢几个数量级。
作为一名性能工程师，我看到的大部分都是错误。
--戴夫
答案2
假设您有两个不同的 RAID 组，可以想象出许多导致性能差异的可能原因。仅仅因为两个存储库都由 4 磁盘 RAID5 支持，您不能指望性能相似。
可能的原因：
- 磁盘速度较慢或损坏
- 较慢的 RAID 控制器
- 文件支持与逻辑卷支持
- 本地与远程（NFS、iSCSI）
- 不同的文件系统（如果有文件支持）
- 其他虚拟机消耗的一个存储库的 I/O 性能
- ...
我认为你应该走出虚拟机去进一步调试这个问题。
答案3
如果这些阵列是网络安装，请确保机器和较慢阵列之间的任何东西都没有因为某种原因被降低到~100mbps。
除此之外，还请按照其他人的建议检查硬件故障或争用。