linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Keld Jørn Simonsen" <keld@keldix.com>
To: Leslie Rhorer <lrhorer@satx.rr.com>
Cc: "'Keld Jørn Simonsen'" <keld@keldix.com>,
	'NeilBrown' <neilb@suse.de>,
	linux-raid@vger.kernel.org
Subject: Re: mdadm raid1 read performance
Date: Fri, 6 May 2011 23:53:39 +0200	[thread overview]
Message-ID: <20110506215339.GA24391@www2.open-std.org> (raw)
In-Reply-To: <89.70.16951.22664CD4@cdptpa-omtalb.mail.rr.com>

On Fri, May 06, 2011 at 04:20:39PM -0500, Leslie Rhorer wrote:
> > -----Original Message-----
> > From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
> > owner@vger.kernel.org] On Behalf Of Keld Jørn Simonsen
> > Sent: Thursday, May 05, 2011 6:10 AM
> > To: NeilBrown
> > Cc: Liam Kurmos; Roberto Spadim; Brad Campbell; Drew; linux-
> > raid@vger.kernel.org
> > Subject: Re: mdadm raid1 read performance
> > 
> > On Thu, May 05, 2011 at 09:45:38AM +1000, NeilBrown wrote:
> > > On Thu, 5 May 2011 00:08:59 +0100 Liam Kurmos <quantum.leaf@gmail.com>
> > wrote:
> > >
> > > > as a separate question, what should be the theoretical performance of
> > raid5?
> > >
> > > x(N-1)
> > >
> > > So a 4 drive RAID5 should read at 3 time the speed of a single drive.
> > 
> > Actually, theoretically, it should be more than that for reading, more
> > like N minus
> > some overhead. In a raid5 stripe of 4 disks, when reading you do not read
> > the checksum block, and thus you should be able to have all 4 drives
> > occupied with reading real data. Some benchmarks back this up,
> > http://home.comcast.net/~jpiszcz/20080329-raid/
> > http://blog.jamponi.net/2008/07/raid56-and-10-benchmarks-on-26255_10.html
> > The latter reports a 3.44 times performance for raid5 reads with 4
> > disks, significantly over the N-1 = 3.0 mark.
> > 
> > For writing, you are correct with the N-1 formular.
> 
> 	There have been a lot of threads here about array performance, but
> one important factor rarely mentioned in these threads is network
> performance.  Of course, network performance is really outside the scope of
> this list, but I frequently see people talking about performance well in
> excess of 120MBps.  That's great, but I have to wonder if their network
> actually can make use of such speeds.  Of course, if the application
> actually obtaining the raw data is on the machine, then network performance
> is much less of an issue.  A database search implemented directly on the
> server, for example, can use every bit of performance available to the local
> machine.  Given that in my case the vast majority of data is squirted across
> the LAN (e.g., these are mostly file servers), anything much in excess of
> 120MBps is irrelevant.  I mean, yeah, it’s a rather nice feeling that my
> RAID arrays can deliver more than 450MBps if they are ever called upon to do
> so, but with a 1G LAN, that's not going to happen very often.  I just wonder
> how many people who complain of poor performance can really benefit all that
> much from increased performance?

10 Gbit/s connections are getting commonplace these days, at least in the
environments that I operate in.

Best regards
keld
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2011-05-06 21:53 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-04  0:07 mdadm raid1 read performance Liam Kurmos
2011-05-04  0:57 ` John Robinson
2011-05-06 20:44   ` Leslie Rhorer
2011-05-06 21:56     ` Keld Jørn Simonsen
2011-05-04  0:58 ` NeilBrown
2011-05-04  5:30   ` Drew
2011-05-04  6:31     ` Brad Campbell
2011-05-04  7:42       ` Roberto Spadim
2011-05-04 23:08         ` Liam Kurmos
2011-05-04 23:35           ` Roberto Spadim
2011-05-04 23:36           ` Brad Campbell
2011-05-04 23:45           ` NeilBrown
2011-05-04 23:57             ` Roberto Spadim
2011-05-05  0:14             ` Liam Kurmos
2011-05-05  0:20               ` Liam Kurmos
2011-05-05  0:25                 ` Roberto Spadim
2011-05-05  0:40                   ` Liam Kurmos
2011-05-05  7:26                     ` David Brown
2011-05-05 10:41                       ` Keld Jørn Simonsen
2011-05-05 11:38                         ` David Brown
2011-05-06  4:14                           ` CoolCold
2011-05-06  7:29                             ` David Brown
2011-05-06 21:05                       ` Leslie Rhorer
2011-05-07 10:37                         ` David Brown
2011-05-07 10:58                           ` Keld Jørn Simonsen
2011-05-05  0:24               ` Roberto Spadim
2011-05-05 11:10             ` Keld Jørn Simonsen
2011-05-06 21:20               ` Leslie Rhorer
2011-05-06 21:53                 ` Keld Jørn Simonsen [this message]
2011-05-07  3:17                   ` Leslie Rhorer
2011-05-05  4:06           ` Roman Mamedov
2011-05-05  8:06             ` Nikolay Kichukov
2011-05-05  8:39               ` Liam Kurmos
2011-05-05  8:49                 ` Liam Kurmos
2011-05-05  9:30               ` NeilBrown
2011-05-04  7:48       ` David Brown

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=20110506215339.GA24391@www2.open-std.org \
    --to=keld@keldix.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=lrhorer@satx.rr.com \
    --cc=neilb@suse.de \
    /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;
as well as URLs for NNTP newsgroup(s).