Re: [Qemu-discuss] qcow2 performance improve

[Jakob Bohm]

On 15/08/2018 17:06, Alberto Garcia wrote:
> On Wed, Aug 15, 2018 at 02:22:30PM +0800, address@hidden wrote:
> > > > When use cluster_size=1M qcow2 newly created to test "32k rand
> > > > write" in the VM,We get low performance within VM。But there
> > > > are huge “write” requests in HOST which falls into qemu
> > > > stack of"perform_cow".
> > > The reason why this happens is because clusters are the smallest
> > > units of allocation in qcow2. So if you write a new cluster you
> > > have to fill it completely with data. If there was any existing
> > > data (backing file, snapshot), you need to copy it from there.
> > > If cluster_size=1M then every time you send a write request that
> > > needs to allocate a new cluster then you need to write 1MB. It
> > > doesn't matter if the write request is 32KB, 4KB or 512 bytes.
> > But Our image has not backing file or snapshot.
> If there is no backing file or snapshot you still need to fill the
> cluster with zeroes, and that's going to be slower with larger
> clusters.
>
> More information here:
>
>     https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg01229.html
>
> There's work to improve that scenario (allocating a new cluster with no
> backing file or snapshots), here are some patches:
>
>     http://lists.nongnu.org/archive/html/qemu-block/2018-05/msg00180.html
>
> More information about those patches here:
>
>     http://lists.nongnu.org/archive/html/qemu-devel/2017-11/msg00059.html
>
> And that's for the "no backing file" case. The more general solution
> would be the subcluster allocation feature that I mentioned in my
> previous e-mail:
>
>     https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg01033.html
>
> I gave a presentation last year at the KVM Forum about performance
> with the qcow2 format:
>
>     https://www.youtube.com/watch?v=kmUxIOTiGNo
>
> Another earlier talk on the same topic by Max Reitz and Kevin Wolf:
>
>     https://www.youtube.com/watch?v=svMpxzl9yI4
>
> I hope that helps,
>
> Berto
And don't forget the high-speed solution: Create the qcow2 file with all
clusters preallocated in contiguous file clusters in a non-fragmented file
on the underlying physical disk(s).

I believe there are qemu-img options to create such qcow2 files instead of
a "thin-provisioned" qcow2 file where each virtual cluster written by the
VM will require the qcow2 layer to allocate and map a new cluster from the
underlying file system file, often in a non-ideal physical disk layout.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded