All of lore.kernel.org
 help / color / mirror / Atom feed
From: Donald Thompson <dlt@dataventures.com>
To: linux-lvm@sistina.com
Subject: [linux-lvm] Apparent performance degradation for each PV with striping
Date: Sun, 18 Mar 2001 22:11:29 -0700	[thread overview]
Message-ID: <3AB59501.FF6ED9F3@dataventures.com> (raw)

I started playing with iostat tonight and saw a few things I didn't
really expect to see.

I've got a volume group consisting of 4 82 gig drives. All 4 are IDE
drives.
Reading directly from the raw device, a PV in this case, with something
like

dd if=/dev/ide/host0/bus0/target0/lun0/disc of=/dev/null

gave me around 5500 blocks read per second.
Reading from a unstriped LV on a single PV gives me around
4500 blocks read per second, which I felt was reasonable. When I create
a LV striped across all four, my blocks read per second drops to around
1100
per hard drive, giving me a total of about 4400 reads per second for
that LV.
2200 reads per second if I striped it across 2 PV's. Timing how long it
took
to finish a dd for the different types of LV's I made pretty much
confirmed what
iostat was saying. It always took me 45 seconds, give or take a second,
to
read a 100 megabyte LV. So it appears striping is useless for me,
atleast with this
hardware setup.

I notice during the dd operation that my system CPU state is 90% or
more.
So I think I just answered my own question, I'm CPU bound. Moving on,
is there any known ways to improve my performance off each PV with this
type of
hardware setup? I usually create an LV with...

lvcreate -i4 -I4 -L somesize vgname -n lvname

Should I expect that I won't see the performance drop on individual PV's
with striping
on SCSI drives? I originally setup this system with no intentions of it
being a high performance
file server, until a few people I work with decided they wanted to use
it for a database machine.
So I'm not afraid to spend a couple grand to get some faster disks in it
if thats the only thing
thats gonna help me.

My system:

Linux 2.4.2
Libc 2.1.3
Debian Potato
LVM 0.9.1_beta6 utilities and patch.
ATA 100 IDE interfaces on MB
idebus set to 66 in /etc/lilo.conf
CPU is Athlon 1000mhz thunderbird
256 megs of RAM

-Don

             reply	other threads:[~2001-03-19  5:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-19  5:11 Donald Thompson [this message]
2001-03-19  5:20 ` [linux-lvm] Apparent performance degradation for each PV with striping Eric M. Hopper
2001-03-22  8:55   ` Russell Coker
2001-03-19  6:03 ` lvm
2001-03-19  7:05   ` Donald Thompson
2001-03-19  9:15     ` Joe Thornber
2001-03-19  7:06   ` Jason Walker
2001-03-19  8:48 ` Oleg Volkov
  -- strict thread matches above, loose matches on Subject: below --
2001-03-19 13:34 S. Michael Denton
2001-03-19 13:44 ` Steven Lembark
2001-03-22  8:54   ` Russell Coker
2001-03-22  9:53     ` Ragnar Kjørstad
2001-03-22 12:19     ` zoo1
2001-03-22  8:58 ` Russell Coker

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=3AB59501.FF6ED9F3@dataventures.com \
    --to=dlt@dataventures.com \
    --cc=linux-lvm@sistina.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.