Performance

同一台機器上兩個磁碟的顯著磁碟 I/O 性能差異

  • June 24, 2013

通過 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。在對xvda關係 %sy:%wa 進行 dd-ing 期間，它看起來大致像 20%:80%，在 dd-ing 期間xvdb它幾乎看起來像 0%:100%。

現在最大的問題是：WTF？我已經沒有如何進一步追查根本原因的想法了。有什麼想法可以解決這個問題嗎？

非常感謝您的幫助！

我將添加一些額外的資訊：

  • 兩個儲存庫都支持 LVM
  • 兩者都是 Xen 主機本地的
  • 奇怪：更快的儲存庫包含超過 20 個其他 VM（和xvda此 VM）的虛擬磁碟；disks xvdb/xvdc是較慢儲存庫中唯一的磁碟，並且僅附加到此 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”在內的 AFAICS 仍然沒有輸出任何指向壞磁碟的東西……還有其他可以辨識壞磁碟的檢查嗎？謝謝！

由於性能差異如此之大，假設存在錯誤 (:-))

嚴肅地說，常見的意外悲觀問題會使你的速度減慢 10-20%。性能錯誤，例如前面提到的死磁碟，會使您的速度降低幾個數量級。

作為一名性能工程師，我看到的大部分都是錯誤。

–戴夫

鑑於您有兩個不同的 RAID 集，可以想像性能差異的許多可能原因。僅僅因為兩個儲存庫都由 4 磁碟 RAID5 支持，您不能期望性能相似。

可能的原因：

  • 較慢或即將死去的磁碟
  • 較慢的 RAID 控制器
  • 文件支持與邏輯卷支持
  • 本地與遠端（NFS、iSCSI）
  • 不同的文件系統（如果文件支持）
  • 其他虛擬機消耗的一個儲存庫的 I/O 性能
  • …

我認為您應該在虛擬機之外進行進一步調試。

引用自：https://serverfault.com/questions/517562

相關問答

Performance

為什麼順序寫入比 SSD 上的隨機寫入具有更好的性能？

  • January 27, 2021
檢視問答
Performance

桁架 -D 和桁架 -E 有什麼區別？

  • November 21, 2014
檢視問答
Performance

對 RAID 0 性能的性能期望不合理？

  • July 20, 2014
檢視問答
Ubuntu

備份期間如何限制磁碟 i/o？

  • June 5, 2013
檢視問答
Performance

沒有回寫記憶體的 RAID10 = 糟糕的寫入性能？

  • October 29, 2012
檢視問答
Performance

Windows 磁碟 I/O 分析

  • May 24, 2010
檢視問答