Bug 526381

Summary:	qcow2 performance bad under i/o load
Product:	[Fedora] Fedora	Reporter:	Kevin Fenzi <kevin>
Component:	qemu	Assignee:	Kevin Wolf <kwolf>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	high
Version:	rawhide	CC:	berrange, chellwig, dwmw2, gcosta, itamar, jaswinder, jforbes, markmc, quintela, virt-maint
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-10-05 14:48:46 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	498968

Description Kevin Fenzi 2009-09-30 04:08:26 UTC

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 19:20:53 UTC

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 07:57:29 UTC

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 23:18:59 UTC

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 07:41:34 UTC

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 14:48:46 UTC

Closing not a bug since it is expected that compression impedes performance.