Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

My KVM guest does max. 200MB/s although the host does easily > 700MB/s (Raid 0 with 4 SSDs).

Configuration: File-based storage (raw), cache none.

Host 24 cores, 96GB ram, Ubuntu 12.04.1 LTS and virt-manager.

I suspect the CPU to be the bottleneck (one core goes up during hdparm).

Anyone experienced the same or has an explanation ?

Edit: one more info: guest is the same as host (Ubuntu 12). Same poor disk performance observed with Windows 2008 R2 and Suse Enterprise Linux (9 or 10 I think). Max 1 guest running.

share|improve this question

2 Answers 2

OK...

  1. [ ] virtio drivers?
  2. file based images will always be slower than raw images served by LVM etc because the filesystem (VFS) overhead is still there.
  3. It sounds like you're sharing image space with host operating system. So when the HV hits swap or gets busy for other reasons that will really impeded guest performance.

KVM tuning guide, features RH but all the recommendations are generic. http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/topic/liaat/liaatbestpractices_pdf.pdf

CPU is usually the last place you look for io performance bottlenecks, pining vcpus might be a good idea though to isolate things. I/O is complex and isn't direct as many think. It functions as a writeback system and is heavily dependent on how much ram you have, the width of your memory buses, and how swappiness is tuned among a host of other tunables. There's no silver bullet or "flat rate" solution, it usually isn't the obvious symptom. Things like linux-perf and systemtap can help diagnose where the bottleneck is and identify the root cause. Good luck.

share|improve this answer
    
Using VirtIO drivers. And the host and other VMs are idle/off. Regarding file as storage, additional overhead: for sure, but not 70%... –  Alex Oct 9 '12 at 20:50
    
Thanks for your support btw ;) –  Alex Oct 9 '12 at 20:57
    
You can make all the assumptions you want, until you start testing them you'll never get to the bottom of it. Yes, it can be that bad as you're putting a block device at the mercy of the file cache. iostat, vmstat, and blktrace are your friends. Or just create another VM with direct access and compare performance. This is work, and you won't get to the bottom of it unless you help yourself. –  ppetraki Oct 10 '12 at 13:57

I started using write-back as cache mode and then at least peaks reach the 700mb/s.

As write-back is not as safe as cache mode none I enabled filesystem (ext3) barriers in the Linux VMs as safety measure.

On Windows however the guest blue-screens which is not that important yet.

share|improve this answer
    
Not as safe is a massive understatement, you traded speed for data integrity. No one runs with writeback mode in production. Good Luck. –  ppetraki Oct 17 '12 at 13:33
    
According to the link you provided writeback should be safe as well when using barriers... –  Alex Oct 18 '12 at 6:55
    
it's "safer" but not the same as writethrough, if you suffer a fault between barriers that data is gone. writeback systems are usually backed up by RAIDs with BBC (battery backed cache) or UPS. Barriers aren't magical. –  ppetraki Oct 18 '12 at 17:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.