All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Peter Rabbitson <rabbit+list@rabbit.us>
Cc: Michael Guntsche <mike@it-loops.com>,
	Maurice Hilarius <maurice@harddata.com>,
	linux-raid@vger.kernel.org
Subject: Re: Severe slowdown with LVM on RAID, alignment problem?
Date: Sat, 01 Mar 2008 15:45:58 -0500	[thread overview]
Message-ID: <47C9C086.4020805@tmr.com> (raw)
In-Reply-To: <47C7E086.5080203@rabbit.us>

Peter Rabbitson wrote:
> Michael Guntsche wrote:
>>
>> Is it possible that my computer is just too slow to get good read 
>> results?
> unlikely
>
>> While reading is a little bit faster it's nowhere near the speed I 
>> get on
>> md0 itself.
>>
>
> I would guess that you did not set the correct read-ahead values for 
> the LV. If you do not specify anything it will default to 128k (256 
> sectors), which is terribly small for sequential reads. On the 
> contrary the MD device will do some clever calculations and set its 
> read-ahead correctly depending on the raid level and the number of 
> disks. Do:
>
> blockdev --setra 65536 <your lv device>
>
> and run the tests again. You are almost certainly going to get the 
> results you are after.

I will just comment that really large readahead values may cause 
significant memory usage and transfer of unused data. My observations 
and some posts indicate that very large readahead and/or chunk size may 
reduce random access performance. I believe you said you had 512MB RAM, 
that may be a factor as well.

Also, blockdev will allow you to diddle readahead on the device, 
/dev/sdX, the array /dev/mdX, and the lv /dev/mapper/NAME. The 
interaction of these, and the performance results of having the same 
exact amount of readhead memory used in different way is a fine topic 
for a thesis, conference paper, magazine article, or nightmare.

Unless you are planning to use this machine mainly for running 
benchmarks, I would tune it for your actual load and a bit of worst case 
avoidance.

-- 
Bill Davidsen <davidsen@tmr.com>
  "Woe unto the statesman who makes war without a reason that will still
  be valid when the war is over..." Otto von Bismark 



  parent reply	other threads:[~2008-03-01 20:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-29  8:12 Severe slowdown with LVM on RAID, alignment problem? Michael Guntsche
2008-02-29 10:37 ` Peter Rabbitson
2008-02-29 10:45   ` Michael Guntsche
2008-03-01 20:45   ` Bill Davidsen [this message]
2008-03-01 21:26     ` Michael Guntsche
2008-03-02 20:14       ` Bill Davidsen
2008-03-04 19:52         ` Severe slowdown with LVM on RAID, alignment problem? - Autodetect? Janek Kozicki
     [not found] <47C75436.9010301@harddata.com>
2008-02-29  7:37 ` Severe slowdown with LVM on RAID, alignment problem? Michael Guntsche
  -- strict thread matches above, loose matches on Subject: below --
2008-02-29  0:05 Michael Guntsche

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=47C9C086.4020805@tmr.com \
    --to=davidsen@tmr.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=maurice@harddata.com \
    --cc=mike@it-loops.com \
    --cc=rabbit+list@rabbit.us \
    /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.