Bug 526381 - qcow2 performance bad under i/o load
qcow2 performance bad under i/o load
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
All Linux
high Severity medium
: ---
: ---
Assigned To: Kevin Wolf
Fedora Extras Quality Assurance
Depends On:
Blocks: F12VirtBlocker
  Show dependency treegraph
Reported: 2009-09-30 00:08 EDT by Kevin Fenzi
Modified: 2009-10-05 10:48 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-10-05 10:48:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Kevin Fenzi 2009-09-30 00:08:26 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.
Comment 1 Mark McLoughlin 2009-10-01 15:20:53 EDT
Thanks for testing Kevin

That's certainly not good given that qcow2 performance is a Fedora 12 feature

Could you include:

  - virsh dumpxml $guest
  - /var/log/libvirt/qemu/$guest.log
  - 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?
Comment 2 Kevin Wolf 2009-10-02 03:57:29 EDT
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?
Comment 3 Kevin Fenzi 2009-10-03 19:18:59 EDT
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?
Comment 4 Kevin Wolf 2009-10-05 03:41:34 EDT
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.
Comment 5 Justin M. Forbes 2009-10-05 10:48:46 EDT
Closing not a bug since it is expected that compression impedes performance.

Note You need to log in before you can comment on or make changes to this bug.