Linux RAID subsystem development
 help / color / mirror / Atom feed
From: Joe Landman <joe.landman@gmail.com>
To: mark delfman <markdelfman@googlemail.com>
Cc: Linux RAID Mailing List <linux-raid@vger.kernel.org>
Subject: Re: single cpu thread performance limit?
Date: Thu, 11 Aug 2011 15:57:01 -0400	[thread overview]
Message-ID: <4E44340D.7060402@gmail.com> (raw)
In-Reply-To: <CAACGR8to9iybX+fJ_CGYBFgR6XtgPoqCt8kFA4mpqo4d1jEMqw@mail.gmail.com>

On 08/11/2011 03:37 PM, mark delfman wrote:

> So, a single RAID10 creates a single thread - which will max at maybe 200K IOPS.

We are seeing ~110k IOPs per PCI HBA for an SSD variant of what you 
have.  FWIW, MD RAID is significantly faster than the hardware RAID 
here, but that's due to the processor more than anything else.

Which cards if you don't mind my asking?  We work with a number of 
vendors in this space.

> Create 4 x RAID10's seems OK, but they will not scale so great with a
> RAID0 on top :(
> Ideal would be a few threads per RAIDx

[...]

> Whilst a R0 on top of the R1/10's does offer some increase in
> performance, linear does not :(

Linear makes no sense for distributing IO's among many devices.  Linear 
is a concatenation.

> LVM R0 on top of the MD R1/10's does much the same results.
> The limiter seems fixes on the single thread per R1/10

Whats your CPU?  What's your 'lspci -vvv' output look like (is it 
possible you've oversubscribed your PCIe channels?)  How many PCIe lanes 
do you have on your MB?

FWIW, our array of SSD's hit 7.8 GB/s and 330k IOPs (8k random reads 
against 768GB of data) using MD RAID5's.  Each RAID5 hits around 75k 
IOPs, and when joined together, they hit closer to 110k per HBA.

The PCIe units are generally much better than this.  Last set of cards 
we played with a few weeks ago we were getting about 400k IOPs for a 
pair of cards in an MD RAID0.  I expect newer drivers and other things 
to help out a bit.


-- 
Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics Inc.
email: landman@scalableinformatics.com
web  : http://scalableinformatics.com
        http://scalableinformatics.com/sicluster
phone: +1 734 786 8423 x121
fax  : +1 866 888 3112
cell : +1 734 612 4615

  reply	other threads:[~2011-08-11 19:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-11 15:58 single cpu thread performance limit? mark delfman
2011-08-11 16:01 ` Mathias Burén
2011-08-11 16:07   ` mark delfman
2011-08-11 18:58 ` Stan Hoeppner
2011-08-11 19:37   ` mark delfman
2011-08-11 19:57     ` Joe Landman [this message]
2011-08-12  9:04       ` David Brown
2011-08-11 20:51     ` Stan Hoeppner
2011-08-12  1:05       ` Stan Hoeppner
2011-08-12 12:48     ` Asdo
2011-08-12 13:23   ` mark delfman
2011-08-12 14:23     ` Asdo
2011-08-12 20:51     ` Stan Hoeppner
2011-08-11 19:04 ` Bernd Schubert

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=4E44340D.7060402@gmail.com \
    --to=joe.landman@gmail.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=markdelfman@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