linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Keld Jørn Simonsen" <keld@dkuug.dk>
To: David Rees <drees76@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: raind-1 resync speed slow down to 50% by the time it finishes
Date: Fri, 31 Jul 2009 19:54:55 +0200	[thread overview]
Message-ID: <20090731175455.GA11463@rap.rap.dk> (raw)
In-Reply-To: <72dbd3150907301311t5abef2fai91cdae154b987d33@mail.gmail.com>

On Thu, Jul 30, 2009 at 01:11:20PM -0700, David Rees wrote:
> 2009/7/30 Keld Jørn Simonsen <keld@dkuug.dk>:
> > I think raid10,f2 only degrades 10-20 % while raid1 can degrade as much
> > as 50 %. For writing it is about the same, given that you use a file
> > system on top of the raid.
> 
> Has anyone done any benchmarks of near vs far setups?

Yes, there are a number of benchmarks on raid10 near/far scenarios
at http://linux-raid.osdl.org/index.php/Performance

> >From what I understand, here's how performance should go for a 2-disk
> raid10 setup:
> 
> Streaming/large reads far: Up to 100% faster since reads are striped
> across both disks

and possibly faster, due to far only using the faster half of the disk
for reading.

> Streaming/large reads near: Same as single disk as reads can't be
> striped across both disks

yes.

> Streaming/large writes far: Slower than single disk, since disks have
> to seek to write.  How much of a hit in performance will depend on
> chunk size.
> Streaming/large writes near: Same as single disk.

Due to the elevator of the file system, writes are about the same for
both near and far.

> Random/small reads far: Up to 100% faster

Actually a bit more, due to that far only uses the fastest half of the
disks. One test shows 132 % faster, which is consistent with theory.

> Random/small reads near: Up to 100% faster

One test shows 156 % faster.

> Random/small writes far: Same as single disk.
> Random/small writes near: Same as single disk.

yes.

> So basically, if you have a setup which mostly reads from disk, using
> a far layout is beneficial, but if you have a setup which does a
> higher percentage of writes, sticking to a near layout will be faster.

For reading, this is true, but for writing, it is not true, given that
you use a filesystem, with an elevator algorithm in use. The elevator
evens out the lesser performance of layout=far for a raw raid10,f2, so
that the performance is about the same for the near and far layouts.

> I recently set up an 8-disk RAID10 across 8 7200 disks across 3 controllers.
> 
> 5 disks are in an external enclosure via eSATA and a PCIe card.
> 2 disks are using onboard SATA controller
> 1 disk is using onboard IDE controller
> 
> I debated whether or not to use near or far, but ultimately stuck with
> near for two reasons:
> 
> 1. The array mostly sees write activity, streaming reads aren't that common.
> 2. I can only get about 120 MB/s out of the external enclosure because
> of the PCIe card [1] , so being able to stripe reads wouldn't help get
> any extra performance out of those disks.

Hmm, a pci-e x1 should be able to get 2.5 Mbit/s = about 300 MB/s. 
Wikipedia says 250 MB/s. It is strange that you only can get 120 MB/s.
That is the speed of a PCI 32 bit bus. I looked at your reference [1]
for the 3132 model. Have you tried it out in practice?

The max you should be able to get out of your raid10 with 8 disks would
then be around 400 - 480 MB/s, for sequential reads. 250 MB/s out of your PCIE
enclosure, or 50 MB/s per disk, and then additional 50 MB/s each of the last
3 disks. You can only multiply the speed of the slowest of the disks
involved by the number of disks. But even then it is not so bad.
For random read it is better yet, given that this is not limited by the
transfer speed of your PCIe controller.

> -Dave
> 
> [1] http://ata.wiki.kernel.org/index.php/Hardware,_driver_status#Silicon_Image_3124
> --
> 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

  reply	other threads:[~2009-07-31 17:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-30  6:25 raind-1 resync speed slow down to 50% by the time it finishes Tirumala Reddy Marri
2009-07-30  7:35 ` Robin Hill
2009-07-30 10:18   ` Keld Jørn Simonsen
2009-07-30 20:11     ` David Rees
2009-07-31 17:54       ` Keld Jørn Simonsen [this message]
2009-07-31 18:10         ` Keld Jørn Simonsen
2009-07-31 20:10         ` David Rees
2009-08-01 13:00           ` Keld Jørn Simonsen
2009-08-01 15:13             ` David Rees
2009-08-01 17:57               ` Keld Jørn Simonsen
2009-08-04 22:21                 ` David Rees
2009-08-04 23:18                   ` John Robinson
2009-08-04 23:42                     ` David Rees
2009-08-05  8:20                       ` Keld Jørn Simonsen
2009-08-05  8:08                     ` Keld Jørn Simonsen
2009-08-05  7:44                   ` Keld Jørn Simonsen
2009-08-05  8:18                     ` NeilBrown
2009-07-30  8:44 ` Mikael Abrahamsson
2009-07-30 18:35 ` Tracy Reed
2009-07-30 20:28   ` David Rees

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=20090731175455.GA11463@rap.rap.dk \
    --to=keld@dkuug.dk \
    --cc=drees76@gmail.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 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).