All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Robinson <john.robinson@anonymous.org.uk>
To: Ryan Wagoner <rswagoner@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: High IO Wait with RAID 1
Date: Fri, 13 Mar 2009 14:48:31 +0000	[thread overview]
Message-ID: <49BA723F.8020905@anonymous.org.uk> (raw)
In-Reply-To: <7d86ddb90903121646q485ad12y90824a4c3fcc2dfd@mail.gmail.com>

On 12/03/2009 23:46, Ryan Wagoner wrote:
[...]
> Both systems exhibit the same issues on the RAID 1 drives. That rules
> out the drive brand and controller card. During any IO intensive
> process the IO wait will raise and the system load will climb.

I'm sorry if this sounds flippant, but what did you expect?

> I've
> had the IO wait as high as 70% and the load at 13+ while migrating a
> vmdk file with vmware-vdiskmanager. You can easily recreate the issue
> with bonnie++.
> 
> I can perform the same disk intensive operation on the RAID 5 array
> with almost no io wait or load. What is the deal with this? Is there
> something I can tweak?

I suspect your RAID-5 array has higher thoughput available - reading and 
writing across 3 discs rather than 2 - and what you're doing isn't quite 
maxing out its throughput, whereas it does on the 2-disc RAID-1. I 
imagine you would see the same thing on a single disc.

Bear in mind that iowait time needn't be wasted; run a few copies of 
something CPU intensive at the same time and you will see zero iowait.

High system load isn't necessarily a problem either; I once had a busy 
web server where the system load went from about 5 one day to over 200 
the next. Cue much panicking trying to find out what had happened. 
Turned out the web designers had made the home page 70K instead of 60K, 
so a lot of httpd processes sending to slow links were stalled when 
previously the whole lot would have been in network buffers. It still 
worked fine in that there was no detectable performance problem, it was 
just an alarming-looking system load.

Cheers,

John.


  parent reply	other threads:[~2009-03-13 14:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-12 23:46 High IO Wait with RAID 1 Ryan Wagoner
2009-03-13  0:48 ` Alain Williams
2009-03-13  3:21   ` Ryan Wagoner
2009-03-13  9:39     ` Robin Hill
2009-03-13 10:17     ` Alain Williams
     [not found]       ` <7d86ddb90903130519p4268dc33vc8ad42b53aefa2e2@mail.gmail.com>
2009-03-13 12:21         ` Fwd: " Ryan Wagoner
2009-03-13 16:22     ` Bill Davidsen
2009-03-13 17:42       ` Ryan Wagoner
2009-03-13 18:37         ` David Rees
2009-03-13 18:42   ` David Rees
2009-03-13 14:48 ` John Robinson [this message]
2009-03-13 18:02 David Lethe
2009-03-13 18:29 ` Ryan Wagoner
2009-03-13 22:10   ` 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=49BA723F.8020905@anonymous.org.uk \
    --to=john.robinson@anonymous.org.uk \
    --cc=linux-raid@vger.kernel.org \
    --cc=rswagoner@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.