我在使用基于xen的服务器时遇到了严重的问题，这是在客户分区上。 这是一个半虚拟化的CentOS 5.5。 我不确定是硬件还是软件相关，还是介于两者之间（驱动程序）。
基本信息
更新的控制器固件（这是作为最后一步完成的）
Smart Array 6i in Slot 0 Hardware Revision: Rev B Firmware Version: 2.84 更新的内核
Linux domU 2.6.18-194.32.1.el5xen #1 SMP Wed Jan 5 19:32:33 EST 2011 i686 i686 i386 GNU/Linux
问题在于磁盘写入速度。
基线performance是
在networking上复制大文件时，从顶部取下列数字。
如果我再次复制文件速度相对于平均负载下降。 所以第二次是第一次的速度的一半。
这之后需要一些时间来冷静下来。 负载平均值缓慢下降，直到再次可用。 ls /大约需要30秒。
top - 13:26:44 up 13 days, 21:44, 2 users, load average: 7.03, 5.08, 3.15 Tasks: 134 total, 2 running, 132 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0%us, 0.1%sy, 0.0%ni, 25.3%id, 74.5%wa, 0.0%hi, 0.0%si, 0.1%st Mem: 1048752k total, 1041460k used, 7292k free, 3116k buffers Swap: 2129912k total, 40k used, 2129872k free, 904740k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1506 root 10 -5 0 0 0 S 0.3 0.0 0:03.94 cifsd 1 root 15 0 2172 644 556 S 0.0 0.1 0:00.08 init
同时主机平均负载平均值为0.5，并且稳定。 〜50％等
服务器硬件是双xeon，3gb内存，170gb scsi 320 10k rpm，并且在通过networking复制文件时不应该有任何问题。
disk = [ "tap:aio:/vm/domU.img,xvda,w" ]
我也得到这些日志
INFO: task syslogd:1350 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. syslogd D 00062E4F 2208 1350 1 1353 1312 (NOTLB) c0ef0ed0 00000286 6e71a411 00062e4f c0ef0f18 00000009 c0f20000 6e738bfd 00062e4f 0001e7ec c0f2010c c181a724 c1abd200 00000000 ffffffff c0ef0ecc c041a180 00000000 c0ef0ed8 c03d6a50 00000000 00000000 c03d6a00 00000000 Call Trace: [<c041a180>] __wake_up+0x2a/0x3d [<ee06a1ea>] log_wait_commit+0x80/0xc7 [jbd] [<c043128b>] autoremove_wake_function+0x0/0x2d [<ee065661>] journal_stop+0x195/0x1ba [jbd] [<c0490a32>] __writeback_single_inode+0x1a3/0x2af [<c04568ea>] do_writepages+0x2b/0x32 [<c045239b>] __filemap_fdatawrite_range+0x66/0x72 [<c04910ce>] sync_inode+0x19/0x24 [<ee09b007>] ext3_sync_file+0xaf/0xc4 [ext3] [<c047426f>] do_fsync+0x41/0x83 [<c04742ce>] __do_fsync+0x1d/0x2b [<c0405413>] syscall_call+0x7/0xb =======================
我已经尝试禁用irqbalanced 这里build议，但它似乎没有任何区别。
更新：
domU# cat /sys/block/xvda/queue/scheduler [noop] anticipatory deadline cfq
从/向磁盘复制文件导致加载保持<4。随后的复制导致负载增加。 通过networking复制文件导致第一次运行时负载大于4，随后的复制导致服务器几乎完全停止，需要时间冷却，永不停机，只需要10-15分钟即可恢复。 但是对于服务器来说，这样做确实是不可行的。
networkingstream量本身不会造成任何麻烦，例如运行iperf不会产生任何可衡量的影响。 报告的带宽大于1gbit。
在dom0上写入性能是可以的
dom0# dd if=/dev/zero of=./test1024M bs=1024k count=1024 conv=fsync 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 34.9725 seconds, 30.7 MB/s
写在domU上的performance是缓慢的
domU# dd if=/dev/zero of=./test1024M bs=1024k count=1024 conv=fsync 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 622.163 seconds, 1.7 MB/s
这是〜95％的performance损失。
阅读performance还可以
dom0# hdparm -tT /dev/cciss/c0d0p1 /dev/cciss/c0d0p1: Timing cached reads: 3352 MB in 2.00 seconds = 1676.70 MB/sec Timing buffered disk reads: 100 MB in 2.59 seconds = 38.57 MB/sec domU# hdparm -tT /dev/xvda /dev/xvda: Timing cached reads: 3144 MB in 2.00 seconds = 1571.51 MB/sec Timing buffered disk reads: 120 MB in 3.03 seconds = 39.67 MB/sec
更新：
所以看来这毕竟是硬件相关的。 但直到运行xen才显示出来。 电池没有充电好，这导致caching被禁用。 这与运行密集IO的虚拟机相结合导致了高等待时间。
现在，升级固件后立即没有任何改变，但自固件升级以来，电池现在正在正确充电。 而且在电池充满后，写入速度现在可以接受了，对于小文件来说超过了dom0，不知道为什么会发生这种情况。
domU# dd if=/dev/zero of=./test1024M bs=1024k count=1024 conv=fsync 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 39.1087 seconds, 27.5 MB/s
我会把它归咎于你的主机上使用的旧的xen版本（CentOS 5.5）。 我真的可以推荐使用SLES 10或11. 11内置了XEN 4.x。
我在SLES 10 Dom0上运行的CentOS 5 DomU没有性能问题。