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
next prev 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.