All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark van Walraven <markv@netvalue.net.nz>
To: Malinka Rellikwodahs <aelmalinka@gmail.com>
Cc: kvm@vger.kernel.org
Subject: Re: kvm-83 write performance raw
Date: Tue, 3 Mar 2009 09:53:30 +1300	[thread overview]
Message-ID: <20090302205330.GC20969@netvalue.net.nz> (raw)
In-Reply-To: <aa2a0fc0903021211p4651b0bek4fe055b97033216b@mail.gmail.com>

On Mon, Mar 02, 2009 at 03:11:59PM -0500, Malinka Rellikwodahs wrote:
> when running with a raw disk image as a file or a raw disk image on an
> lvm vg, I'm getting very low performance on write (5-10 MB/s) however
> when using qcow2 format disk image the write speed is much better
> (~30MB/s), which is consistant with a very similar setup running
> kvm-68.  Unfortunately when running the test with qcow2 the system
> becomes unresponsive for a brief time during the test.

> The host is running raid5 and drbd (drive replication software),
> however performance on the host is performaning well and avoiding the
> drbd layer in the guest does not improve performance, but running on
> qcow2 does.
> 
> Any thoughts/suggestions of what could be wrong or what to do to fix this?

RAID1 has *much* better write performance.  With striping RAIDs, alignment
is important.  RAID controllers sometimes introduce hidden alignment
offsets.  Excessive read-ahead is a waste of time with a lot of small
random I/O, which is what I see mostly with guests on flat disk images.

With LVM, it pays to make sure the LVs are aligned to the disk.  I prefer
boundaries with multiples of at least 64-sectors, which makes the LVM
overhead virtually disappear.  I align the guest filesystems too, when
I can.

I don't think DRBD has an effect on alignment, but you might look at
keeping the metadata on another drive.

Block - rather than file - images are much faster.

Hope this helps,

Mark.

  parent reply	other threads:[~2009-03-02 21:19 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-02 20:11 kvm-83 write performance raw Malinka Rellikwodahs
2009-03-02 20:35 ` Anthony Liguori
2009-03-02 20:37   ` Malinka Rellikwodahs
2009-03-02 20:39     ` Malinka Rellikwodahs
2009-03-02 21:22       ` Anthony Liguori
2009-03-02 21:39         ` Malinka Rellikwodahs
2009-03-02 22:21           ` Anthony Liguori
2009-03-09 15:09           ` Avi Kivity
2009-03-02 20:53 ` Mark van Walraven [this message]
2009-03-02 21:00   ` Malinka Rellikwodahs
2009-03-03 15:13     ` Nikola Ciprich
     [not found]       ` <aa2a0fc0903051110q528da32ek17b0f6468d0f15ff@mail.gmail.com>
2009-03-05 19:11         ` Fwd: " Malinka Rellikwodahs
2009-03-06  0:14           ` Malinka Rellikwodahs
2009-03-09 15:40           ` Fwd: " Nikola Ciprich
2009-03-04 22:28   ` Paolo Pedaletti
2009-03-05  2:09     ` Mark van Walraven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090302205330.GC20969@netvalue.net.nz \
    --to=markv@netvalue.net.nz \
    --cc=aelmalinka@gmail.com \
    --cc=kvm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.