From: Bill Davidsen <davidsen@tmr.com>
To: Al Boldi <a1426z@gawab.com>
Cc: Justin Piszcz <jpiszcz@lucidpixels.com>,
linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org,
xfs@oss.sgi.com
Subject: Re: Linux Software RAID 5 Performance Optimizations: 2.6.19.1: (211MB/s read & 195MB/s write)
Date: Fri, 12 Jan 2007 15:32:13 -0500 [thread overview]
Message-ID: <45A7F04D.6030804@tmr.com> (raw)
In-Reply-To: <200701122235.30288.a1426z@gawab.com>
Al Boldi wrote:
> Justin Piszcz wrote:
>
>> RAID 5 TWEAKED: 1:06.41 elapsed @ 60% CPU
>>
>> This should be 1:14 not 1:06(was with a similarly sized file but not the
>> same) the 1:14 is the same file as used with the other benchmarks. and to
>> get that I used 256mb read-ahead and 16384 stripe size ++ 128
>> max_sectors_kb (same size as my sw raid5 chunk size)
>>
>
> max_sectors_kb is probably your key. On my system I get twice the read
> performance by just reducing max_sectors_kb from default 512 to 192.
>
> Can you do a fresh reboot to shell and then:
> $ cat /sys/block/hda/queue/*
> $ cat /proc/meminfo
> $ echo 3 > /proc/sys/vm/drop_caches
> $ dd if=/dev/hda of=/dev/null bs=1M count=10240
> $ echo 192 > /sys/block/hda/queue/max_sectors_kb
> $ echo 3 > /proc/sys/vm/drop_caches
> $ dd if=/dev/hda of=/dev/null bs=1M count=10240
>
You can find even more joy on large writes, assuming you have a recent
2.6 kernel. Look at /proc/sys/vm/dirty-* values. by making the ratio
smaller, and the ratio smaller you can reduce or eliminate the bursty
behavior of Linux disk write. However, see my previous thread on poor
RAID-5 write performance, there's still something not optimal. Note that
RAID-10, which does more i/o, is faster with default tuning than RAID-5
by about N-1 taime (N = array drives).
I would say that the numbers posted are interesting, but most people
don't have a spare GB or more to use for buffer, particularly if you
have multiple arrays on your disks.
Before someone says "why do that..." here's why:
/boot - should be mirrored so the BIOS will boot if a drive fails
swap - RAID-1, because for an given tuning, it's faster than RAID-5.
Note: RAID-10 is faster yet, but Fedora
and SuSE rescue CDs don't like RAID-10 swap.
critical - stuff you can't afford to lose, RAID-6\
normal - RAID-5
That's why I have partitions of the same drives at different RAID
levels, and with various tuning settings, depending on how they are used.
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
[[HTML alternate version deleted]]
prev parent reply other threads:[~2007-01-12 20:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-11 23:38 Linux Software RAID 5 Performance Optimizations: 2.6.19.1: (211MB/s read & 195MB/s write) Justin Piszcz
2007-01-12 14:01 ` Michael Tokarev
2007-01-12 14:38 ` Justin Piszcz
2007-01-12 17:37 ` Justin Piszcz
2007-01-12 19:49 ` Al Boldi
2007-01-12 19:56 ` Justin Piszcz
2007-01-12 20:15 ` Justin Piszcz
2007-01-12 20:41 ` Bill Davidsen
2007-01-12 21:00 ` Al Boldi
2007-01-12 21:40 ` Justin Piszcz
2007-01-13 6:11 ` Al Boldi
2007-01-13 9:40 ` Justin Piszcz
2007-01-12 20:32 ` Bill Davidsen [this message]
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=45A7F04D.6030804@tmr.com \
--to=davidsen@tmr.com \
--cc=a1426z@gawab.com \
--cc=jpiszcz@lucidpixels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=xfs@oss.sgi.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;
as well as URLs for NNTP newsgroup(s).