我有一台运行Xen的服务器和一些虚拟机。 我正在尝试设置一个专门用于虚拟机的RAIDarrays，它将用于各种存储密集型的目的。 目前，在从domU（一个拥有大量vcpus和内存的Debian PV客户端）写入数据时，我的性能下降了很多。
目前，我的设置是，我有三个3TB的WD红色硬盘驱动器安排在dom0（软件）RAID 5arrays。 目前，dom0正在虚拟机上/dev/mdX块作为/dev/xvdb （该虚拟机具有来自LVM卷的/dev/xvda ）。 xen config的相关位：
disk = [ <LVM stuff for xvda>, 'phy:/dev/md0,xvdb,w' ]
/dev/md0有一个ext4文件系统，使用了noatime, nodiratime选项。 当我对domU的文件系统进行速度testing时，得到如下的结果：
# dd if=/dev/zero of=a_file bs=1M count=1024 conv=fsync 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 16.2694 s, 66.0 MB/s # dd if=some_other_noncached_file of=/dev/null bs=1M 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 26.379 s, 163 MB/s
但是，在dom0中，我得到：
# dd if=/dev/zero of=a_file_somewhere bs=1M count=1024 conv=fsync 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 6.80677 s, 158 MB/s
这显然是一个非常大的速度差异。 虽然66 MB / s现在应该足够好，但是如果有人能够解释为什么我的写入性能下降了60％，我真的很感激它吗？ 我预计10％左右，但不是60％。
这不是资源匮乏，因为我一直在给它提供比应有的更多的资源，问题仍然存在。 这也不是domU资源匮乏，而且我已经固定了CPU保持在同一个NUMA节点上，并且结果是相同的。
这里有一些从xl info可能相关的东西：
host : <hostname> release : 3.16.0-4-amd64 version : #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04) machine : x86_64 nr_cpus : 24 max_cpu_id : 63 nr_nodes : 2 cores_per_socket : 6 threads_per_core : 2 cpu_mhz : 2660 hw_caps : bfebfbff:2c100800:00000000:00003f00:029ee3ff:00000000:00000001:00000000 virt_caps : hvm total_memory : 24573 free_memory : 12011 sharing_freed_memory : 0 sharing_used_memory : 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 4 xen_extra : .1 xen_version : 4.4.1 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=0xffff800000000000 xen_changeset : xen_commandline : placeholder dom0_mem=8192M dom0_max_vcpus=8 dom0_vcpus_pin cc_compiler : gcc (Debian 4.9.2-10) 4.9.2 cc_compile_by : ultrotter cc_compile_domain : debian.org cc_compile_date : Thu Jun 11 18:24:17 EEST 2015 xend_config_format : 4
如果还有其他可能有用的东西，请让我知道，我会更新这个问题。
谢谢！
我已经看到了与PV客人的本地磁盘性能接近，MD的工作在dom0和domU两个层次上完成。
如果可以，请尝试将guest虚拟机设置为半虚拟化（PV）而不是硬件虚拟机（HVM）。
另外，对于PV或HVM，尝试将整个驱动器分配给来宾，并让它处理RAID（MD）。
看看什么最适合你。
还有一些调查发现，这不是一个独特的问题（请参阅https://bugzilla.redhat.com/show_bug.cgi?id=500145 ）。 在这里提出一些build议后，对iostat进一步调查表明，domU上的平均写入大小低于128KiB，而在dom0上大约是512KiB（通过除以wkB/s / w/s ）。
一些谷歌search引起了一个事实，即这是一个已知的问题，在12月份提交了一个修补程序，通过将内核模块参数xen_blkfront.max的默认值从32提高到128来“解决”该问题。通过重写默认值我自己（在VM的GRUBconfiguration中），domU上的写入速度从大约65MiB / s跃升到大约115MiB / s，这足够奖金，我不会再看太多了。
所以，虽然还有更多的领域可以覆盖（从115 MiB / s到150 MiB / s的dom0速度），但是主要的烦人的部分已经被修复了，所以我把它标记为解决scheme（我可以）。 我会更新与任何更多的调整，或者是我发现哪些提供重大影响。