mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Miquel van Smoorenburg" <miquels@cistron.nl>
To: linux-kernel@vger.kernel.org
Subject: Re: 3Ware 9500S-12 RAID controller -- poor performance
Date: Wed, 5 Oct 2005 20:07:44 +0000 (UTC)	[thread overview]
Message-ID: <di1bqg$te6$1@news.cistron.nl> (raw)
In-Reply-To: <20050930065058.84446.qmail@web30315.mail.mud.yahoo.com>

In article <20050930065058.84446.qmail@web30315.mail.mud.yahoo.com>,
subbie subbie  <subbie_subbie@yahoo.com> wrote:
>I'm using a 3Ware 9500S-12 card and am able to produce
>up to 400MB/s sustained read from my 12-disk 4.1TB
>RAID5 SATA array, 128MB cache onboard, ext3 formatted.
>  All is well when performing a single read -- it
>works nice and fast.
>
>The system is a web server, serving mid-size files
>(50MB, each, on average).  All hell breaks loose when
>doing many concurrent reads, anywhere between 200 to
>400 concurrent streams things simply grind to a halt
>and the system transfers a maximum of 12-14MB/s.

There are a couple of things you should do:

1. Use the CFQ I/O scheduler, and increase nr-requests:
   echo cfq > /sys/block/hda/queue/scheduler
   echo 1024 > /sys/block/hda/queue/nr_requests

2. Make sure that your filesystem knows about the stripe size
   and number of disks in the array. E.g. for a raid5 array
   with a stripe size of 64K and 6 disks (effectively 5,
   because in every stripe-set there is on disk doing parity):

   # ext3 fs, 5 disks, 64K stripe, units in 4K blocks
   mkfs -text3 -E stride=$((64/4))

   # xfs, 5 disks, 64K stripe, units in 512 bytes
   mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))

3. Don't use partitions. Partions do not start on a multiple of
   the (stripe_size * nr_disks), so your I/O will be misaligned
   and the settings in (2) will have no or an adverse effect.
   If you must use partitions, either build them manually
   with sfdisk so that partitions do start on that multiple,
   or use LVM.

4. Reconsider your stripe size for streaming large files.
   If you have say 4 disks, and a 64K
   stripe size, then a read of a block of 256K will busy all 4 disks.
   Many simultaneous threads reading blocks of 256K will result in
   trashings disks as they all want to read from all 4 disks .. so
   in that case, using a stripesize of 256K will make things better.
   One read of 256K (in the ideal, aligned case) will just keep one
   disk busy. 4 reads can happen in parallel without trashing. Esp.
   in this case, you need the alignment I talked about in (3).

5. Defragment the files.
   If the files are written sequentially, they will not be fragmented.
   But if they were stored by writing to thousands of them appending
   a few K at a time in round-robin fashion, you need to defragment..
   in the case of XFS, run xfs_fsr every so often.

Good luck,

Mike.


  parent reply	other threads:[~2005-10-05 20:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-30  6:50 subbie subbie
2005-10-02  0:07 ` Ian Morgan
2005-10-05  6:43   ` subbie subbie
2005-10-05 11:25     ` Dr. David Alan Gilbert
2005-10-05 13:08       ` subbie subbie
2005-10-05 13:18         ` Dr. David Alan Gilbert
2005-10-05 13:39           ` subbie subbie
2005-10-05 13:40     ` Ian E. Morgan
2005-10-06  7:34       ` subbie subbie
2005-10-03 14:34 ` Ville Herva
2005-10-05 20:07 ` Miquel van Smoorenburg [this message]
2005-09-30  6:51 subbie subbie
2005-10-07 21:35 Jon Burgess
2005-10-10 10:42 ` subbie subbie
2005-10-10 10:54   ` Dr. David Alan Gilbert
2005-10-10 11:07     ` Mikael Abrahamsson
2005-10-10 11:22     ` subbie subbie
2005-10-10 12:36       ` Mikael Abrahamsson

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='di1bqg$te6$1@news.cistron.nl' \
    --to=miquels@cistron.nl \
    --cc=linux-kernel@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

all inboxes | Powered by JetHome®