All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keld Simonsen <keld@keldix.com>
To: Jon Nelson <jnelson-linux-raid@jamponi.net>
Cc: LinuxRaid <linux-raid@vger.kernel.org>
Subject: Re: very strange raid10,f2 performance
Date: Sat, 1 May 2010 00:46:42 +0200	[thread overview]
Message-ID: <20100430224642.GB7127@rap.rap.dk> (raw)
In-Reply-To: <k2mcccedfc61004211002p24f1bd21xdead3e501766553f@mail.gmail.com>

On Wed, Apr 21, 2010 at 12:02:46PM -0500, Jon Nelson wrote:
> I was helping somebody else diagnose some issues, and decided to run
> comparitive tests on my own raid (raid10,f2).
> 
> The raid10,f2 (md0) is the only physical device backing a volume
> group, which is then carved into a bunch of (primarily) ext4
> filesystems.
> The kernel is 2.6.31.12 (openSUSE) on a Quad Processor AMD Phenom 9150e system.
> The raid is two Western Digital Caviar Blue drives (WDC WD5000AAKS-00V1A0).
> 
> The problem: really, really bad I/O performance under certain circumstances.
> 
> When using an internal bitmap and *synchronous* I/O, applications like
> dd report 700-800 kB/s.
> When not using a bitmap at all, and synchronous I/O, dd reports 2.5
> MB/s (but dstat shows 14MB/s?)
> Without a bitmap and async I/O (but with fdatasync) I get 65MB/s.
> *With* a bitmap and using async. I/O (but with fdatasync) I get more
> like 65MB/s.
> 
> The system has 3GB of memory and I'm testing with dd if=/dev/zero
> of=somefile bs=4k count=524288.
> 
> I'm trying to understand why the synchronous I/O is so bad, but even
> so I was hoping for more. 65MB/s seems *reasonable* given the
> raid10,f2 configuration and all of the seeking that such a
> configuration involves (when writing).
> 
> The other very strange thing is that the I/O patterns seem very
> strange. I'll see 14MB/s very consistently as reported by dstat
> (14MB/s for each sda, sdb, and md0) for 10-15 seconds and then I'll
> see it drop, sometimes to just 3 or 4 MB/s, for another 10 seconds,
> and then the pattern repeats.  What's going on here? With absolutely
> no other load on the system, I would have expected to see something
> much more consistent.

Hmm, not much response to this.
The only idea I have for now is misalignment between raid and LVM boundaries.

Were your dd's done on the raw devices, or via a file system?

Best regards
keld

  reply	other threads:[~2010-04-30 22:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-21 17:02 very strange raid10,f2 performance Jon Nelson
2010-04-30 22:46 ` Keld Simonsen [this message]
2010-05-01  1:35   ` Jon Nelson
2010-05-01  8:36     ` Keld Simonsen
2010-05-02  1:40       ` Jon Nelson

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=20100430224642.GB7127@rap.rap.dk \
    --to=keld@keldix.com \
    --cc=jnelson-linux-raid@jamponi.net \
    --cc=linux-raid@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.