Red Hat Bugzilla – Bug 526381
qcow2 performance bad under i/o load
Last modified: 2009-10-05 10:48:46 EDT
Seeing the improved qcow2 performance feature I decided to try it out here.
I used qemu-img to convert some raw format guests over to qcow2 with compression.
At first everything looked great. Guests came up fine and acted ok.
However, as soon as I put i/o load on them, things didn't do so well.
Doing a mock build in a guest basically made it have large chunks of time when it wouldn't respond at all, stopped answering pings and appeared hung. It would then recover and repeat.
I tried this with a f11 and a rawhide guest with the same effect on both.
Could this be the compression?
I switched everything back to raw, but I can reconvert one for further testing if it helps.
Thanks for testing Kevin
That's certainly not good given that qcow2 performance is a Fedora 12 feature
Could you include:
- virsh dumpxml $guest
- the qemu-img convert command you're using
- qemu-img info $guest
- host and guest kernel versions, qemu-kvm version
kwolf: perhaps you could try and reproduce?
Compression could really hurt speed. Not only do we need to uncompress everything we read (what does your IO look like? Mainly reads or writes?) but we also fall back to reading cluster by cluster. I think that most of the performance optimizations don't help much with compressed (or encrypted) images.
Kevin, could you simply try what happens if you convert to an uncompressed qcow2 image and run that?
Ah, after some testing here, it does indeed appear to be the compression thats to blame.
The exact same image, raw or qcow2 appears to be fine, but compressed qcow2 shows the bad behavior. ;(
So, unless there is some clever way to make this behave better, perhaps we should add a release note/update the feature page to indicate that compression will cause very poor performance?
Do you still want the info from comment #1?
No, I don't think we need additional info. At the same time I think there is no simple thing we can do about it without risking breakage. To a certain degree everyone would expect that compression/encryption slows things down, but if it's really that bad I agree that updating the feature page for F12 sounds like the right thing.
Closing not a bug since it is expected that compression impedes performance.