From: Steven Ihde <x-linux-raid@hamachi.dyndns.org>
To: Guy <bugzilla@watkins-home.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: Looking for the cause of poor I/O performance
Date: Mon, 6 Dec 2004 13:16:07 -0800 [thread overview]
Message-ID: <20041206211607.GA3037@hamachi.dyndns.org> (raw)
In-Reply-To: <200412061929.iB6JTj904159@www.watkins-home.com>
Gotcha. Please excuse the loose use of terminology on my part.
But now I'm more convinced than ever that I should be getting better
performance than I am. I'm getting 40MB/sec from each disk
individually, I've shown with hdparm that I can pull 40MB/sec from all
three disks simultaneously, but still my raid5 read performance (in a
three-disk array) is slightly less than 40MB/sec.
Any guesses what the issue could be? Is there a switch for
read-ahead?
-Steve
On Mon, 06 Dec 2004 14:29:40 -0500, Guy wrote:
> RAID5 can't do read balancing. Any 1 piece of data is only on 1 drive.
> However, RAID5 does do read ahead, my speed is about 3.5 times as fast as a
> single disk. A single disk: 18 M/sec, my RAID5 array, 65 M/sec.
>
> Guy
>
> -----Original Message-----
> From: linux-raid-owner@vger.kernel.org
> [mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Steven Ihde
> Sent: Monday, December 06, 2004 12:49 PM
> To: linux-raid@vger.kernel.org
> Subject: Re: Looking for the cause of poor I/O performance
>
> On Sat, 04 Dec 2004 17:00:08 -0800, Steven Ihde wrote:
> [snip]
> > A possible clue is that when tested individually but in parallel, hda
> > and hdc both halve their bandwidth:
> >
> > /dev/hda:
> > Timing cached reads: 1552 MB in 2.00 seconds = 774.57 MB/sec
> > Timing buffered disk reads: 68 MB in 3.07 seconds = 22.15 MB/sec
> > /dev/hdc:
> > Timing cached reads: 784 MB in 2.00 seconds = 391.86 MB/sec
> > Timing buffered disk reads: 68 MB in 3.02 seconds = 22.54 MB/sec
> > /dev/sda:
> > Timing cached reads: 836 MB in 2.00 seconds = 417.65 MB/sec
> > Timing buffered disk reads: 120 MB in 3.00 seconds = 39.94 MB/sec
> >
> > Could there be contention for some shared resource in the on-board
> > PATA chipset between hda and hdc? Would moving one of them to a
> > separate IDE controller on a PCI card help?
> >
> > Am I unreasonable to think that I should be getting better than 37
> > MB/sec on raid5 read performance, given that each disk alone seems
> > capable of 40 MB/sec?
>
> To answer my own question... I moved one of the PATA drives to a PCI
> PATA controller. This did enable me to move 40MB/sec simultaneously
> from all three drives. Guess there's some issue with the built-in
> PATA on the ICH5R southbridge.
>
> However, this didn't help raid5 performance -- it was still about
> 35-39MB/sec. I also have a raid1 array on the same physical disks,
> and observed the same thing there (same read performance as a single
> disk with hdparm -tT, about 40 MB/sec). So:
>
> 2.6.8 includes the raid1 read balancing fix which was mentioned
> previously on this list -- should this show up as substantially better
> hdparm -tT numbers for raid1 or is it more complicated than that?
>
> Does raid5 do read-balancing at all or am I just fantasizing?
>
> Thanks,
>
> Steve
> -
> 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
>
> -
> 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
next prev parent reply other threads:[~2004-12-06 21:16 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-02 16:38 Looking for the cause of poor I/O performance TJ
2004-12-03 0:49 ` Mark Hahn
2004-12-03 3:54 ` Guy
2004-12-03 6:33 ` TJ
2004-12-03 7:38 ` Guy
2004-12-04 15:23 ` TJ
2004-12-04 17:59 ` Guy
2004-12-04 23:51 ` Mark Hahn
2004-12-05 1:00 ` Steven Ihde
2004-12-06 17:48 ` Steven Ihde
2004-12-06 19:29 ` Guy
2004-12-06 21:10 ` David Greaves
2004-12-06 23:02 ` Guy
2004-12-08 9:24 ` David Greaves
2004-12-08 18:31 ` Guy
2004-12-08 22:00 ` Steven Ihde
2004-12-08 22:25 ` Guy
2004-12-08 22:41 ` Guy
2004-12-09 1:40 ` Steven Ihde
2004-12-12 8:56 ` [linux-lvm] Re: Looking for the cause of poor I/O performance - a test script David Greaves
2004-12-12 8:56 ` David Greaves
2004-12-28 0:13 ` [linux-lvm] " Steven Ihde
2004-12-28 0:13 ` Steven Ihde
2004-12-06 21:16 ` Steven Ihde [this message]
2004-12-06 21:42 ` documentation of /sys/vm/max-readahead Morten Sylvest Olsen
2004-12-05 2:16 ` Looking for the cause of poor I/O performance Guy
2004-12-05 15:14 ` TJ
2004-12-06 21:39 ` Mark Hahn
2004-12-05 15:17 ` TJ
2004-12-06 21:34 ` Mark Hahn
2004-12-06 23:06 ` Guy
2004-12-03 6:51 ` TJ
2004-12-03 20:03 ` TJ
2004-12-04 22:59 ` Mark Hahn
2004-12-03 7:12 ` TJ
-- strict thread matches above, loose matches on Subject: below --
2004-12-03 11:30 TJ
2004-12-03 11:46 ` Erik Mouw
2004-12-03 15:09 ` TJ
2004-12-03 16:25 ` Erik Mouw
2004-12-03 16:32 ` David Greaves
2004-12-03 16:50 ` Guy
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=20041206211607.GA3037@hamachi.dyndns.org \
--to=x-linux-raid@hamachi.dyndns.org \
--cc=bugzilla@watkins-home.com \
--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 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.