Description of problem:
I've had to disable raid-check because the check/resync process absolutely kills performance. Server is used for backups and for multiple kvm guests so a fair amount of IO.
Version-Release number of selected component (if applicable):
# cat /proc/mdstat
Personalities : [raid1] [raid10]
md1 : active raid10 sdb2 sde1 sdf1 sdg1 sdh1 sdc1 sdd1 sda2
3906203648 blocks 256K chunks 2 near-copies [8/8] [UUUUUUUU]
md0 : active raid1 sdb1 sda1
200704 blocks [2/2] [UU]
Since RHEL 6.2 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.
Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.
It seems to be the combination of kvm guests and the raid10 resync that kills IO performance for some reason. Stopping all kvm guests during the resync (or stopping the resync if it is just a check) gets me back to >100MB/s read/write performance.
The kvm guests are using raw lvm volumes on a volume group on the raid10 array and using virtio. One kvm guest in particular that triggers it is a 2 cpu Fedora 14 instance running zabbix-server - so a fairly steady cpu and io load.
I just noticed that a copy between two disks on the host was crawling (5-10MB/s). I starting shutting down kvm guests (which were mainly idle) and now I'm up to 50-70MB/s. Something about kvm guests is really killing the host IO performance.
Any chance that having hyperthreading enabled would have any effect on this? I may disable just to see.
This is the controller I'm using:
07:00.0 SCSI storage controller: LSI Logic / Symbios Logic MegaRAID SAS 8208ELP/8208ELP (rev 08)
with mptsas driver.
This appears to be fixed in recent kernels. Feel free to close.
Still happens on F16 latest kernel BTW.
Is this a regular F16 system? If so I would open a new bug against F16. I'm not seeing any trouble now with a current 6.2 system.