* [linux-lvm] performance comparison soft-hardware RAID + LVM: bad
@ 2002-10-15 17:39 Ron Arts
2002-10-16 3:28 ` Heinz J . Mauelshagen
2002-10-16 3:57 ` Jon Bendtsen
0 siblings, 2 replies; 6+ messages in thread
From: Ron Arts @ 2002-10-15 17:39 UTC (permalink / raw)
To: linux-lvm
[-- Attachment #1: Type: text/plain, Size: 2962 bytes --]
Hello,
I am interested in performance for hardware/software RAID
in combination with LVM
So I took a server (Dual Xeon 2.4GHz, 1Gb RAM), a RAID adapter,
some identical SCSI disks and configured it with several of these
options (using RH 8.0) and ran a few bonnie++ benchmarks.
Results are below. Anyone care to comment? Especially LVM performance
disappointed here.
LVM machine setup:
2 18Gb disks. I created 3 partitions on both disks, 128Mb, 512Mb and 17Gb
Equal partitions were combined into RAID-1 devices (md driver).
First md device mounted on /boot, second for swapfile, and third
as basis for LVM
Out of the volume group four LV were created and mounted as follows:
[root@nbs-126 root]# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/vg0/root 4225092 1293064 2717400 33% /
/dev/md0 124323 11517 106387 10% /boot
/dev/vg0/home 4225092 32828 3977636 1% /home
none 514996 0 514996 0% /dev/shm
/dev/vg0/var 4225092 51720 3958744 2% /var
/dev/vg0/mysql 16513960 32828 15642272 1% /var/lib/mysql
Is there a reason for the performance degradation I saw with LVM?
Regards,
Ron Arts
Version 1.02c ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
nbs-126.offic 2008M 24005 99 66015 49 16148 7 27430 98 86915 15 369.0 1 single disk
nbs-126.offic 2G 23422 99 70919 58 23800 11 25289 86 101485 17 433.4 1 s/w RAID-1
nbs-126.offic 2G 8152 99 49897 94 23092 27 9122 92 78056 38 331.1 2 s/w RAID-1 + LVM
nbs-126.offic 4032M 19695 99 44056 42 14179 9 21526 94 86450 16 344.3 1 h/w RAID-1
nbs-126.offic 4032M 19916 99 24033 22 13343 9 22794 99 111662 30 388.5 1 h/w RAID-5
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
nbs-126.office.n 16 2481 99 +++++ +++ +++++ +++ 2424 99 +++++ +++ 5508 98 single disk
nbs-126.office.n 16 2530 99 +++++ +++ +++++ +++ 2437 99 +++++ +++ 6062 100 s/w RAID-1 soft
nbs-126.office.n 16 800 99 +++++ +++ 12848 98 807 99 +++++ +++ 2591 99 s/w RAID-1 + LVM
nbs-126.office.n 16 2138 98 +++++ +++ 31126 98 2200 99 +++++ +++ 5322 98 h/w RAID-1
nbs-126.office.n 16 2182 99 +++++ +++ 27238 86 2172 98 +++++ +++ 5261 97 h/w RAID-5
Notes:
The last two are with hardware RAID (GDT 4513RZ), and 2Gb RAM instead of 1, but I adjusted
the -s parameter for bonnie++ accordingly.
commandline:
# ./bonnie++ -d /tmp -s 2048 -x2 -uroot
Results shown are for the second run. Machines were otherwise inactive, and carried a
minimum install.
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3291 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] performance comparison soft-hardware RAID + LVM: bad
2002-10-15 17:39 Ron Arts
@ 2002-10-16 3:28 ` Heinz J . Mauelshagen
2002-10-16 3:57 ` Jon Bendtsen
1 sibling, 0 replies; 6+ messages in thread
From: Heinz J . Mauelshagen @ 2002-10-16 3:28 UTC (permalink / raw)
To: linux-lvm
On Wed, Oct 16, 2002 at 12:17:49AM +0200, Ron Arts wrote:
> Hello,
>
> I am interested in performance for hardware/software RAID
> in combination with LVM
>
> So I took a server (Dual Xeon 2.4GHz, 1Gb RAM), a RAID adapter,
> some identical SCSI disks and configured it with several of these
> options (using RH 8.0) and ran a few bonnie++ benchmarks.
>
> Results are below. Anyone care to comment? Especially LVM performance
> disappointed here.
>
> LVM machine setup:
>
> 2 18Gb disks. I created 3 partitions on both disks, 128Mb, 512Mb and 17Gb
> Equal partitions were combined into RAID-1 devices (md driver).
> First md device mounted on /boot, second for swapfile, and third
> as basis for LVM
>
> Out of the volume group four LV were created and mounted as follows:
>
> [root@nbs-126 root]# df
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/vg0/root 4225092 1293064 2717400 33% /
> /dev/md0 124323 11517 106387 10% /boot
> /dev/vg0/home 4225092 32828 3977636 1% /home
> none 514996 0 514996 0% /dev/shm
> /dev/vg0/var 4225092 51720 3958744 2% /var
> /dev/vg0/mysql 16513960 32828 15642272 1% /var/lib/mysql
Ron, I don't get your configuration by this df output :(
You've got 3 mirrored MDs on 2 disks (1st: 128Mb, 2nd: 512Mb, 3rd: 17Gb)
3rd is used as the one and only physical volume (say /dev/md2)
for volume group "vg0", right?
How comes that the grand total of /dev/vg0/{root, home, var, mysql}
is ~27.84Gb when the volume group only holds the 17Gb of /dev/md2?
>
> Is there a reason for the performance degradation I saw with LVM?
If my above thoughts are correct, the logical volume(s) used could well be
suffering from bad mapping onto disk(s). You can check the mapping with
either "pvdisplay -v /dev/md2" or for eg. "lvdisplay -v /dev/vg00/root".
I don't feel sure about your MD configuration either.
Hope that spots some light on those numbers which differ from mine
(typically LVM gives a performamce enhancement for sequential input).
The mapping overhead of the LVM1 driver is in the sub percent order.
Regards,
Heinz -- The LVM Guy --
>
> Regards,
> Ron Arts
>
>
> Version 1.02c ------Sequential Output------ --Sequential Input- --Random-
> -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
> Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
> nbs-126.offic 2008M 24005 99 66015 49 16148 7 27430 98 86915 15 369.0 1 single disk
> nbs-126.offic 2G 23422 99 70919 58 23800 11 25289 86 101485 17 433.4 1 s/w RAID-1
> nbs-126.offic 2G 8152 99 49897 94 23092 27 9122 92 78056 38 331.1 2 s/w RAID-1 + LVM
> nbs-126.offic 4032M 19695 99 44056 42 14179 9 21526 94 86450 16 344.3 1 h/w RAID-1
> nbs-126.offic 4032M 19916 99 24033 22 13343 9 22794 99 111662 30 388.5 1 h/w RAID-5
> ------Sequential Create------ --------Random Create--------
> -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
> files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
> nbs-126.office.n 16 2481 99 +++++ +++ +++++ +++ 2424 99 +++++ +++ 5508 98 single disk
> nbs-126.office.n 16 2530 99 +++++ +++ +++++ +++ 2437 99 +++++ +++ 6062 100 s/w RAID-1 soft
> nbs-126.office.n 16 800 99 +++++ +++ 12848 98 807 99 +++++ +++ 2591 99 s/w RAID-1 + LVM
> nbs-126.office.n 16 2138 98 +++++ +++ 31126 98 2200 99 +++++ +++ 5322 98 h/w RAID-1
> nbs-126.office.n 16 2182 99 +++++ +++ 27238 86 2172 98 +++++ +++ 5261 97 h/w RAID-5
>
>
> Notes:
>
> The last two are with hardware RAID (GDT 4513RZ), and 2Gb RAM instead of 1, but I adjusted
> the -s parameter for bonnie++ accordingly.
>
> commandline:
> # ./bonnie++ -d /tmp -s 2048 -x2 -uroot
> Results shown are for the second run. Machines were otherwise inactive, and carried a
> minimum install.
*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf
Germany
Mauelshagen@Sistina.com +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] performance comparison soft-hardware RAID + LVM: bad
2002-10-15 17:39 Ron Arts
2002-10-16 3:28 ` Heinz J . Mauelshagen
@ 2002-10-16 3:57 ` Jon Bendtsen
2002-10-16 11:04 ` Ron Arts
1 sibling, 1 reply; 6+ messages in thread
From: Jon Bendtsen @ 2002-10-16 3:57 UTC (permalink / raw)
To: linux-lvm
Ron Arts wrote:
>
> Hello,
>
> I am interested in performance for hardware/software RAID
> in combination with LVM
i've resently tested hardware vs. software on 3 different
3ware cards, and some IDE disks. My results showed that
software raid was somewhat faster than hardware, but i'd
still prefer hardware because of the handling of one
failing disk. (notice that if you dont get a warning when
a disk fails, you might as well run without raid, or run
raid0)
I've got a repport in .pdf (and .LyX) in english if someone
wants it.
> So I took a server (Dual Xeon 2.4GHz, 1Gb RAM), a RAID adapter,
> some identical SCSI disks and configured it with several of these
> options (using RH 8.0) and ran a few bonnie++ benchmarks.
Mine was a single p3 800, with 512MB memory, and i used tiobench
> Results are below. Anyone care to comment? Especially LVM performance
> disappointed here.
I cant clearly see what is LVM setup and what isnt. Remember that LVM
doesnt allocate blocks sequeltial, but by default the first one free.
So, when you create 3 lv's, and then you mkfs them, then you allocate
at least the first block. Then when you fill the rest of the
filesystem...
you allocate the next blocks. Results are one block in the beginning,
a wide gap, and then the rest of the blocks.
> LVM machine setup:
>
> 2 18Gb disks. I created 3 partitions on both disks, 128Mb, 512Mb and 17Gb
> Equal partitions were combined into RAID-1 devices (md driver).
> First md device mounted on /boot, second for swapfile, and third
> as basis for LVM
>
> Out of the volume group four LV were created and mounted as follows:
>
> [root@nbs-126 root]# df
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/vg0/root 4225092 1293064 2717400 33% /
> /dev/md0 124323 11517 106387 10% /boot
> /dev/vg0/home 4225092 32828 3977636 1% /home
> none 514996 0 514996 0% /dev/shm
> /dev/vg0/var 4225092 51720 3958744 2% /var
> /dev/vg0/mysql 16513960 32828 15642272 1% /var/lib/mysql
>
> Is there a reason for the performance degradation I saw with LVM?
I've done 3 (or 0.5 + 0.5 + 1) benchmarks. The first 2 times i didnt do
it well enough. I dont believe you have done it well enough, you clearly
dont have enough numbers. I found that using tiobench i had to variate
the number of threads (concurrent read/write) and the blocksize, before
i
got the best performance. And it variates alot. (See my .pdf, which i
will
mail to you). I've got lots of numbers. I used gnuplot to create graphs,
but consider using iometer to run your benchmarks, i think it creates
the
graphs for you.
You dont have enough disks, 2 disks might be a widely used common setup,
but
other people use more disks, like 4, 8, ... especialy when using scsi,
which
for some reason doesnt seem to contain as much as IDE disks.
I saw a BIG performance drop when i tried to run tiobench on a smp
system,
but using another benchmark tool, i saw that it was only tiobench, not
the
performance that suffered.
I also saw a _GIGANTIC_ performance drop when i ran software raid0 ontop
of
2 software raid1. (or was it the other way ? (request my repport and see
for
yourself, the included one is regular performance)
JonB
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] performance comparison soft-hardware RAID + LVM: bad
2002-10-16 3:57 ` Jon Bendtsen
@ 2002-10-16 11:04 ` Ron Arts
2002-10-17 4:19 ` [linux-lvm] performance comparison soft-hardware RAID + LVM:bad Jon Bendtsen
0 siblings, 1 reply; 6+ messages in thread
From: Ron Arts @ 2002-10-16 11:04 UTC (permalink / raw)
To: linux-lvm
[-- Attachment #1: Type: text/plain, Size: 3405 bytes --]
Jon Bendtsen wrote:
> Ron Arts wrote:
>
[snip]
(I received your report, thanks)
>
>
>>Results are below. Anyone care to comment? Especially LVM performance
>>disappointed here.
>
>
> I cant clearly see what is LVM setup and what isnt. Remember that LVM
> doesnt allocate blocks sequeltial, but by default the first one free.
> So, when you create 3 lv's, and then you mkfs them, then you allocate
> at least the first block. Then when you fill the rest of the
> filesystem...
> you allocate the next blocks. Results are one block in the beginning,
> a wide gap, and then the rest of the blocks.
>
Sorry, I don't understand. Why the gap?
Omn the other hand, the underlying devices are RAID-1 in software, the
allocation shouldn't matter should it?
>
>
>>LVM machine setup:
>>
>>2 18Gb disks. I created 3 partitions on both disks, 128Mb, 512Mb and 17Gb
>>Equal partitions were combined into RAID-1 devices (md driver).
>>First md device mounted on /boot, second for swapfile, and third
>>as basis for LVM
>>
>>Out of the volume group four LV were created and mounted as follows:
>>
>>[root@nbs-126 root]# df
>>Filesystem 1K-blocks Used Available Use% Mounted on
>>/dev/vg0/root 4225092 1293064 2717400 33% /
>>/dev/md0 124323 11517 106387 10% /boot
>>/dev/vg0/home 4225092 32828 3977636 1% /home
>>none 514996 0 514996 0% /dev/shm
>>/dev/vg0/var 4225092 51720 3958744 2% /var
>>/dev/vg0/mysql 16513960 32828 15642272 1% /var/lib/mysql
>>
>>Is there a reason for the performance degradation I saw with LVM?
>
>
> I've done 3 (or 0.5 + 0.5 + 1) benchmarks. The first 2 times i didnt do
> it well enough. I dont believe you have done it well enough, you clearly
> dont have enough numbers. I found that using tiobench i had to variate
> the number of threads (concurrent read/write) and the blocksize, before
> i
> got the best performance. And it variates alot. (See my .pdf, which i
> will
> mail to you). I've got lots of numbers. I used gnuplot to create graphs,
Okay, but lots of numbers still don't explain why in this particular case
performance was so slow. If I understand why, I can begin to make
optimizations.
To give some background:
I do this because I need such a setup for a particular application
(MySQL high volume logging server). If I understand the issues involved
I can make more informed choices implementing the application.
Should it log using multiple threads or one? Will readers from the
datbase hinder the writing process a lot? What is the best way
to add disks using LVM, without taking a large performance hit?
This server must be up 24x7. I found something called scsirastools
that can deal with hotswapping SCSI disks under software RAID.
I thought I'd first try some benchmarks with bonnie to get a feel
for the issues involved, and seeing the performance (and CPU) hit
for my LVM setup (and having never used LVM before) I decided
to ask you guys about this.
And thanks for your report, at least it confirmed what I
had seen: software raid is faster then hardware.
Regards,
Ron Arts
--
Netland Internet Services
bedrijfsmatige internetoplossingen
http://www.netland.nl Kruislaan 419 1098 VA Amsterdam
info: 020-5628282 servicedesk: 020-5628280 fax: 020-5628281
Does old mail ever arrive?
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3291 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] performance comparison soft-hardware RAID + LVM: bad
[not found] <20021016085753.20974.47952.Mailman@hermes.sistina.com>
@ 2002-10-16 22:47 ` Arie Bant@mail.com
0 siblings, 0 replies; 6+ messages in thread
From: Arie Bant@mail.com @ 2002-10-16 22:47 UTC (permalink / raw)
To: linux-lvm; +Cc: 'Jon Bendtsen'
-----Original Message-----
Date: Wed, 16 Oct 2002 10:34:41 +0200
From: Jon Bendtsen <jon+lvm@silicide.dk>
Organization: Silicide A/S
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] performance comparison soft-hardware RAID + LVM:
bad
Reply-To: linux-lvm@sistina.com
You dont have enough disks, 2 disks might be a widely used common setup, but
other people use more disks, like 4, 8, ... especialy when using scsi, which
for some reason doesnt seem to contain as much as IDE disks.
Jon,
Availability of large SCSI hard disks has nothing to do with it.
Using more spindles is better for performance as a general rule (more
spindles can lead to less head movement, if properly configured, head
movement/rotational delay counts for most of the access time on hard disks.
Also, via SCSI, seeks can be done simultaneously and in overlap with I/O on
other hard disks and/or processor activity), hence you will find that in
SCSI configurations more disks are used for performance reasons.
For this reason only, I keep a stack of, now old, 1/2/4 GB drives to use as
dedicated swap devices and /tmp file systems.
Given the intrinsic limitations, all this is not possible when using IDE, so
the capacity than has to come from large disks, the performance will suffer
accordingly, especially in total system throughput. One of a number of
reasons why you should always go with SCSI when you want performance.
Regards,
Arie Bant.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linux-lvm] performance comparison soft-hardware RAID + LVM:bad
2002-10-16 11:04 ` Ron Arts
@ 2002-10-17 4:19 ` Jon Bendtsen
0 siblings, 0 replies; 6+ messages in thread
From: Jon Bendtsen @ 2002-10-17 4:19 UTC (permalink / raw)
To: linux-lvm
Ron Arts wrote:
>
> Jon Bendtsen wrote:
> > Ron Arts wrote:
[snip]
> > I cant clearly see what is LVM setup and what isnt. Remember that LVM
> > doesnt allocate blocks sequeltial, but by default the first one free.
> > So, when you create 3 lv's, and then you mkfs them, then you allocate
> > at least the first block. Then when you fill the rest of the
> > filesystem...
> > you allocate the next blocks. Results are one block in the beginning,
> > a wide gap, and then the rest of the blocks.
> >
>
> Sorry, I don't understand. Why the gap?
> Omn the other hand, the underlying devices are RAID-1 in software, the
> allocation shouldn't matter should it?
Well, let me try a state of the art (tm) ascii drawing ;-D
disk1 disk2
|-----| |-----|
those you make into a mirror
|-----|
Lets zoom in on that and see how LVM works (unallocated vg)
|---------------------------------------------------------------------------------|
So, you make a lv in this vg
|#--------------------------------------------------------------------------------|
Then you make another
|#¤-------------------------------------------------------------------------------|
You allocate some data for the first lv
|#¤#####--------------------------------------------------------------------------|
You allocate some data for the 2. lv
|#¤#####¤¤¤¤¤¤--------------------------------------------------------------------|
Can you see the trend now ??
when you need a "block" you just get the next free. So, unless you are
carefull, or
make it allocate all on creation, then you get this
|#¤#####¤¤¤¤¤¤##¤#¤#¤#¤#¤¤¤¤####¤¤##¤#¤#¤#¤###¤¤¤¤##¤¤##¤¤##¤¤####¤¤¤¤¤#####¤¤##¤#|
And how do you think this changes your performance ? if you are reading
one BIG file.
that covers several # or ¤
> > I've done 3 (or 0.5 + 0.5 + 1) benchmarks. The first 2 times i didnt do
> > it well enough. I dont believe you have done it well enough, you clearly
> > dont have enough numbers. I found that using tiobench i had to variate
> > the number of threads (concurrent read/write) and the blocksize, before
> > i
> > got the best performance. And it variates alot. (See my .pdf, which i
> > will
> > mail to you). I've got lots of numbers. I used gnuplot to create graphs,
>
> Okay, but lots of numbers still don't explain why in this particular case
> performance was so slow. If I understand why, I can begin to make
> optimizations.
I think it is the default allocation of "blocks" for a lv in a vg.
The point with lots of numbers was that just running one benchmark, with
one concurrent write, aka one "thread" and trying to write one big file,
rather than 10 medium files, doesnt give an adequette view of the
performance.
> To give some background:
> I do this because I need such a setup for a particular application
> (MySQL high volume logging server). If I understand the issues involved
> I can make more informed choices implementing the application.
> Should it log using multiple threads or one? Will readers from the
> datbase hinder the writing process a lot? What is the best way
> to add disks using LVM, without taking a large performance hit?
I see your problem, but since you have many readers/writes, you
NEED to test it with concurrent access, maybe 10-20, or more
> This server must be up 24x7. I found something called scsirastools
> that can deal with hotswapping SCSI disks under software RAID.
good. Think of adding many small scsi disks to your raid setup, and
then make it raid10, or raid1 ontop of raid 0 (or the other way arround,
see my repport for which one kills performance)
the proxy server squid can handle more than one area to store the
files. You'll get greater performance by giving it more small areas,
rather than putting the disks into a larger raid array. MAYBE your
mysql logging server can do the same thing ?
> I thought I'd first try some benchmarks with bonnie to get a feel
> for the issues involved, and seeing the performance (and CPU) hit
> for my LVM setup (and having never used LVM before) I decided
> to ask you guys about this.
understandable, but i think you need to do more benchmarking, with
more than one concurrent access.
> And thanks for your report, at least it confirmed what I
> had seen: software raid is faster then hardware.
Well, it can be. I havent tried with _MANY_ disks, and i havent
tried with cpu load arround 100%. (per cpu). Actualy, as i wrote
somewhere in the repport, i would like if someone parallized the
raid, so you could get linear to the number of harddisks performance,
or fill the pci bus. So, someone who reads this... just parallize the
raid, it's not like the first block needs the next block, or the one
before that, so just create a simple asic, it doesnt need to be fast
just many of them, so the pci bus can be filled. 64bit 66MHz of course
;-D
JonB
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-10-17 4:19 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20021016085753.20974.47952.Mailman@hermes.sistina.com>
2002-10-16 22:47 ` [linux-lvm] performance comparison soft-hardware RAID + LVM: bad Arie Bant@mail.com
2002-10-15 17:39 Ron Arts
2002-10-16 3:28 ` Heinz J . Mauelshagen
2002-10-16 3:57 ` Jon Bendtsen
2002-10-16 11:04 ` Ron Arts
2002-10-17 4:19 ` [linux-lvm] performance comparison soft-hardware RAID + LVM:bad Jon Bendtsen
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.