From: Stan Hoeppner <stan@hardwarefreak.com>
To: Peter Landmann <sfrazt@googlemail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: RAID 5 doesn't scale
Date: Wed, 03 Apr 2013 13:35:11 -0500 [thread overview]
Message-ID: <515C765F.50500@hardwarefreak.com> (raw)
In-Reply-To: <loom.20130403T171527-93@post.gmane.org>
On 4/3/2013 10:31 AM, Peter Landmann wrote:
> Stan Hoeppner <stan <at> hardwarefreak.com> writes:
>
>>
>> On 4/3/2013 6:00 AM, Peter Landmann wrote:
>>
>> You didn't mention your stripe_cache_size value. It'll make a lot of
>> difference. Make sure it's at least 4096. The default is 256.
>
> You are very right.
> I increased it to 4096 - 32768 and the performance increased much.
Be careful here. Increasing stripe_cache_size increases memory
consumption of md dramatically. Formula: stripe_cache_size * 4096
bytes * drive_count = RAM usage. For a 6 drive array that's
stripe_cache_size RAM consumed
4096 96MB
8192 192MB
16384 384MB
32768 768MB
Thus you want to select a value that gives you the best combination of
performance and lowest memory usage, unless you're not concerned about RAM.
> Also i played a bit with deadline parameters and it helped also to increase
> performance.
...
> With Raid 5 and 6 SSDs i got 33936 IOPS (fio settings as before) which is not
> far away from theoretical 40000 (i know from former tests that the performance
> could be increased for some more jobs).
Always test with parallel threads. If you don't you're not getting a
realistic picture of what md/RAID and the hardware are capable of.
> For your info: With Raid 6 and 6 SSDs i got 32526 IOPS which is also a very good
> result.
>
> So i conclude that there is no (big) problem with scalability at this hw level,
> right?
Yes. What this demonstrates is that one Thuban core at 2.8-3.3GHz can
apparently execute the md/RAID5/6 write threads faster than these 6
X25-M G2 SSDs can sink the writes. If your CPU was a 1.6GHz Atom and/or
these were newer SATAIII Sandforce based SSDs, you'd peak a CPU core
long before the SSDs run out of headroom.
> FYI: The scheduler makes the difference. If you alternate writes and reades in
> small steps (R W R R W R W W R ..) then the performce decreases heavily. If you
> group read and write operations (20xW 20xR 20xW ..)then the performance will be
> better. Tested it without raid and a patched fio (and noop scheduler). But
> deadline scheduler can reach the same i learned.
The scheduler can play a difference, but with SSDs noop usually gives
the best results. With some SATA/drive controller combos deadline may
be better. CFQ is rarely, if ever, good for performance.
> Thx for your informations and hints
You bet.
--
Stan
next prev parent reply other threads:[~2013-04-03 18:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-03 11:00 RAID 5 doesn't scale Peter Landmann
2013-04-03 11:21 ` Benjamin ESTRABAUD
2013-04-03 18:34 ` Martin Wilck
2013-04-03 20:38 ` Peter Landmann
2013-04-04 13:40 ` Benjamin ESTRABAUD
2013-04-03 13:18 ` Stan Hoeppner
2013-04-03 15:23 ` keld
2013-04-03 15:31 ` Peter Landmann
2013-04-03 18:35 ` Stan Hoeppner [this message]
2013-04-03 18:23 ` Martin Wilck
2013-04-03 20:36 ` Peter Landmann
2013-04-03 21:19 ` Peter Landmann
2013-04-03 21:24 ` Stan Hoeppner
2013-04-03 21:29 ` Peter Landmann
2013-04-03 21:15 ` Stan Hoeppner
2013-04-03 19:56 ` Roy Sigurd Karlsbakk
2013-04-03 21:12 ` Peter Landmann
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=515C765F.50500@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=linux-raid@vger.kernel.org \
--cc=sfrazt@googlemail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox