From: "Keld Jørn Simonsen" <keld@dkuug.dk>
To: Jon Nelson <jnelson@jamponi.net>
Cc: linux-raid@vger.kernel.org
Subject: Re: raid10,f2 degraded read speed
Date: Thu, 26 Jun 2008 10:17:02 +0200 [thread overview]
Message-ID: <20080626081701.GE23500@rap.rap.dk> (raw)
In-Reply-To: <cccedfc60806251031q536dd88bg3cbeae703558318b@mail.gmail.com>
On Wed, Jun 25, 2008 at 12:31:25PM -0500, Jon Nelson wrote:
> Yep that's me.
Good! I added your name in the wiki.
> > I found the link:
> > http://pycurious.blogspot.com/2007/12/some-raid10-performance-numbers.html
> >
> > Is this Jon Nelson writing this?
> >
> > I added the link + some benchmark from Bill Davidsen to the wiki pages
> > on performance.
>
> Neat! I'll probably be going through a rather more extensive set of tests soon.
> The problem for me is that I have to test on a deployed system.
> The load is insanely low, but I can't exactly try "now do it without
> the LVM layer.".
I think we should actually have more figures from systems in production.
The problem is of cause then what is measured. But is sometimes gives a
much better idea of what can be achieved. For example I have a Linux
mirror site with a raid10,f2 array of 4 1 TB disks, and I have maybe 100
concurrent proftpd processes. The fs produces something like 30 MB/s -
but that is not peak performance. I can then cat an ISO file with
about 60 - 100 MB/s - that is not bad. But the system then only delivers
something like 90 - 130 MB/s where peak seq reading is 320 MB/s in idle
mode. Hmm, I think I normally get something like 200 MB/s for the
sequential read of one file, while there is some other activity, and I
am running a number of heavier administrative tasks right now...
But the point is: how do we measure production performance?
My best guess is that we can only give anedotical evidence, and report
of the admins feel of the system.
Nice to have more benchmarks. Maybe you can write up something for the
wiki?
For the wiki I tend to just make links to the articles with performance results,
instead of integrating them in the wiki. And that probably does not make
due description as all the data on the test sometimes is not readily
referenced in the link.
Anyway what we should do for the wiki is kind of a canonical benchmark
results, so that it is easy to read and not repeated a lot of times, at
least on the main performance page. I think it is fine to have more
tests, maybe on subpages. And then I fear that some of the links will go
away, I would rather have the info incorporated into the wiki.
And to stand the teeth of time, I would like to have performance
expressed in terms of relative performance of raw read speed for one
disk, this figure is most likely very stable even over a 10 years'
timespan.
Best regards
keld
next prev parent reply other threads:[~2008-06-26 8:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-17 14:37 raid10,f2 degraded read speed Keld Jørn Simonsen
2008-06-25 17:25 ` Keld Jørn Simonsen
2008-06-25 17:31 ` Jon Nelson
2008-06-26 8:17 ` Keld Jørn Simonsen [this message]
2008-06-26 12:35 ` Jon Nelson
2008-06-26 13:37 ` Keld Jørn Simonsen
2008-06-26 13:38 ` Jon Nelson
2008-06-26 14:20 ` Keld Jørn Simonsen
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=20080626081701.GE23500@rap.rap.dk \
--to=keld@dkuug.dk \
--cc=jnelson@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 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).