All of lore.kernel.org
 help / color / mirror / Atom feed
From: Goswin von Brederlow <goswin-v-b@web.de>
To: Andrew Burgess <aab@cichlid.com>
Cc: linux raid mailing list <linux-raid@vger.kernel.org>
Subject: Re: Adding more drives/saturating the bandwidth
Date: Wed, 01 Apr 2009 20:06:25 +0200	[thread overview]
Message-ID: <87tz58b65a.fsf@frosties.localdomain> (raw)
In-Reply-To: <1238597796.4604.6.camel@cichlid.com> (Andrew Burgess's message of "Wed, 01 Apr 2009 07:56:36 -0700")

Andrew Burgess <aab@cichlid.com> writes:

>> >> > Hey guys, How do you know if your machine can handle
>> >> adding some more drives to it? How can you check that there
>> >> is enough BUS IO to handle extra sata cards and also that
>> >> the machine is powerful enough to support say an 8 drive
>> >> raid 5...
>
> Look at it from the viewpoint of raid performance rather than disk
> performance. How can the throughput be less with more disks?
>
> So what if your bus bandwidth is saturated now? Then it will be
> saturated with more disks too, but the raid bandwidth should not change,
> it's still the saturation bandwidth.
>
> And if it's not saturated now then the raid throughput will increase
> assuming you can get more disks operating in parallel.
>
> I'm sure there are corner cases we can nitpick but isn't this correct in
> general?

To show a worstcase say you have a 5 disk raid5 with 64k chunk
size. Further say your application writes chunks of 256k to disk at
random offsets (but aligned to 256k). Each write is a nice full
stripe, the parity is calculated and 320k are written.

Now think about the same with 6 disk raid5. Suddenly you have partial
stripes. And the alignment on stripe boundaries is gone too. So now
you need to read 384k (I think) of data, compute or delta (whichever
requires less reads) the parity and write back 384k in 4 out of 6
cases and read 64k and write back 320k otherwise. So on average you
read 277.33k and write 362.66k (= 640k combined). That is twice the
previous bandwidth not to mention the delay for reading.

So by adding a drive your throughput is suddenly halfed. Reading in
degraded mode suffers a slowdown too. CPU goes up too.


The performance of a raid is so much dependent on its access pattern
that imho one can not talk about a general case. But note that the
more drives you have the bigger a stripe becomes and you need larger
sequential writes to avoid reads.

MfG
        Goswin

  parent reply	other threads:[~2009-04-01 18:06 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-26 12:43 Adding more drives/saturating the bandwidth Jon Hardcastle
2009-03-30 15:40 ` Goswin von Brederlow
2009-03-30 16:28   ` Nagilum
2009-03-31  8:23   ` Jon Hardcastle
2009-03-31 13:05     ` Greg Freemyer
2009-03-31 21:07     ` Goswin von Brederlow
2009-04-01  8:15       ` Jon Hardcastle
2009-04-01  8:56       ` Jon Hardcastle
2009-04-01 15:59         ` Goswin von Brederlow
2009-04-01 16:15           ` Greg Freemyer
2009-04-01 14:56       ` Andrew Burgess
2009-04-01 15:17         ` David Lethe
2009-04-01 18:06         ` Goswin von Brederlow [this message]
2009-04-01 18:57           ` Richard Scobie
2009-04-03 20:42             ` Goswin von Brederlow
2009-04-03 21:06               ` Robin Hill

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=87tz58b65a.fsf@frosties.localdomain \
    --to=goswin-v-b@web.de \
    --cc=aab@cichlid.com \
    --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.