From: Richard Scobie <richard@sauce.co.nz>
To: Mark Knecht <markknecht@gmail.com>
Cc: Learner Study <learner.study@gmail.com>,
linux-raid@vger.kernel.org, keld@dkuug.dk
Subject: Re: Linux Raid performance
Date: Sat, 03 Apr 2010 14:14:24 +1300 [thread overview]
Message-ID: <4BB69670.3040303@sauce.co.nz> (raw)
In-Reply-To: <l2j5bdc1c8b1004021739z969b99v6011fcc6fddd470a@mail.gmail.com>
Mark Knecht wrote:
> Once all of that is in place then possibly more cores will help, but I
> suspect even then it probably hard to use 4 billion CPU cycles/second
> doing nothing but disk I/O. SATA controllers are all doing DMA so CPU
> overhead is relatively *very* low.
There is the RAID5/6 parity calculations to be considered on writes and
this appears to be single threaded. There is an experimental multicore
kernel option I believe, but recent discussion indicates there may be
some problems with it.
A very quick test on a box here on a Xeon E5440 (4 x 2.8GHz) and a SAS
attached 16 x 750GB SATA md RAID6. The array is 72% full and probably
quite fragmented and currently the system is idle.
dd if=/dev/zero of=/mnt/storage/dump bs=1M count=20000
20000+0 records in
20000+0 records out
20971520000 bytes (21 GB) copied, 87.2374 s, 240 MB/s
Looking at the outputs of vmstat 5 and mpstat -P ALL 5 during this, one
core (probably doing parity generation) was around 7.56% idle and the
other 3 were around 88.5, 67.5 and 51.8% idle.
The same test run when the system was commissioned and the array was
empty, acheived 565MB/s writes.
Regards,
Richard
next prev parent reply other threads:[~2010-04-03 1:14 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-31 19:42 Linux Raid performance Learner Study
2010-03-31 20:15 ` Keld Simonsen
2010-04-02 3:07 ` Learner Study
2010-04-02 9:58 ` Nicolae Mihalache
2010-04-02 17:58 ` Learner Study
2010-04-02 11:05 ` Keld Simonsen
2010-04-02 11:18 ` Keld Simonsen
2010-04-02 17:55 ` Learner Study
2010-04-02 21:14 ` Keld Simonsen
2010-04-02 21:37 ` Learner Study
2010-04-03 11:20 ` Keld Simonsen
2010-04-03 15:56 ` Learner Study
2010-04-04 1:58 ` Keld Simonsen
2010-04-03 0:10 ` Learner Study
2010-04-03 0:39 ` Mark Knecht
2010-04-03 1:00 ` John Robinson
2010-04-03 1:14 ` Richard Scobie [this message]
2010-04-03 1:32 ` Mark Knecht
2010-04-03 1:37 ` Richard Scobie
2010-04-03 3:06 ` Learner Study
2010-04-03 3:00 ` Learner Study
2010-04-03 19:27 ` Richard Scobie
2010-04-03 18:14 ` MRK
2010-04-03 19:56 ` Richard Scobie
2010-04-04 15:00 ` MRK
2010-04-04 18:26 ` Learner Study
2010-04-04 18:46 ` Mark Knecht
2010-04-04 21:28 ` Jools Wills
2010-04-04 22:38 ` Mark Knecht
2010-04-05 10:07 ` Learner Study
2010-04-05 16:35 ` John Robinson
2010-04-04 22:24 ` Guy Watkins
2010-04-05 13:49 ` Drew
2010-04-04 23:24 ` Richard Scobie
2010-04-05 11:20 ` MRK
2010-04-05 19:49 ` Richard Scobie
2010-04-05 21:03 ` Drew
2010-04-05 22:20 ` Richard Scobie
2010-04-05 23:49 ` Roger Heflin
2010-04-14 20:50 ` Bill Davidsen
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=4BB69670.3040303@sauce.co.nz \
--to=richard@sauce.co.nz \
--cc=keld@dkuug.dk \
--cc=learner.study@gmail.com \
--cc=linux-raid@vger.kernel.org \
--cc=markknecht@gmail.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 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.