RE Re: Performance tunning on LVM2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I understand what you said, but the disk performances are not the probleme...
One simple test to  convince :

I create 2 LV on the same VG (one after the other)
I Launch a writing on these AT THE SAME TIME, so test1 and test2 is writing at the same time

Look the result
suse2:~ # lvcreate -L2G -ntest vg0
  Logical volume "test" created
suse2:~ # lvcreate -L2G -ntest2 vg0
  Logical volume "test2" created


suse2:~ # dd if=/dev/zero of=/dev/vg0/test2 bs=1M count=800
800+0 records in
800+0 records out
838860800 bytes (839 MB) copied, 11.2715 seconds, 74.4 MB/s

suse2:~ # dd if=/dev/zero of=/dev/vg0/test bs=1M count=800
800+0 records in
800+0 records out
838860800 bytes (839 MB) copied, 11,5366 seconde, 72,7 MB/s

I repeat that the two writing has been launch AT THE SAME TIME

It is obvious that it isn't the result of excessive seeking but the LVM2 implementation....

Why LVM2 snaphot COW result disastrous performance on Writing original volume... is there one issue...

Antony MARTINEAU
Service informatique
Tel: 05.45.67.34.35
LIPPI - Solutions de clôture
16440 Mouthiers sur Bohëme

-----linux-lvm-bounces@redhat.com a écrit : -----

A : "LVM general discussion and development" <linux-lvm@redhat.com>
De : "Larry Dickson" <ldickson@cuttedge.com>
Envoyé par : linux-lvm-bounces@redhat.com
Date : 06/06/2008 17:03
Objet : Re: Performance tunning on LVM2

A (linear) volume group made of two physical volumes consists of one PV followed by the other, rather like a "Raid-Linear". If you size the origin logical volume right, you can get one LV (the origin) to fall on one disk, and force the snapshot to land on the other disk. This eliminates back-and-forth seeking to the COW. Whether it solves your problem will depend on how smart the driver is about the read-before-write activity on the origin volume.
 
Other members of the list may have more experience on this. Comments?
 
Larry
 
On 6/6/08, Antony MARTINEAU <Antony.MARTINEAU@lippi.fr> wrote:

The volume group vg0 is the raid0 of two disk (SAS 15000rpm 300G0)
I have only this raid on the server

But i don't understand, imagine i make a volume group  ou of this raid0. It is no possible to snapshot the original volume, am i wrong?

If i make a new VG on another disks, For exemple /dev/vg1/
LVM don't permit to store a snaphot on a different VG than the origin volum.

for exemple /dev/vg0/test cant be snapshoting on /dev/vg1/test.snap

LV test and LV test.snap must be on the same volume, am i wrong ???? so it is impossible to store snapshot on another disk....


Cordialement,

MARTINEAU
Antony

Service informatique

Assistant informatique
LIPPI Management
La Fouillouse
16440 Mouthiers sur Boheme
Tel.: 05.45.67.34.35
Courriel:
antony.martineau@lippi.fr
http://www.lippi.fr




De : "Larry Dickson" <ldickson@cuttedge.com>
Pour : "LVM general discussion and development" <linux-lvm@redhat.com>
Date: 06/06/2008 16:19
Objet : Re: Performance tunning on LVM2





This looks like the result of excessive seeking. Are origin volume and snapshot both on the same physical drive? Is it possible to make a volume group out of two drives, and arrange things so that origin volume and snapshot are hitting different disks?
 
Larry Dickson
Cutting Edge Networked Storage

On 6/6/08, Antony MARTINEAU <Antony.MARTINEAU@lippi.fr> wrote:

Hello,

My configuration:

Server DELL 2860 Intel(R) Xeon(R) CPU  X3230 @ 2.66GHz (Quad Core)

8GB of  memory

2 x SAS 15000 300G0 RAID 0 hardware
SLES 10 SP2

Kernel 2.6.16.60-0.21-xen


i have one volume group vg0 ( whith one PV, the two disks in raid0) whith many lvm

I am very surprise about LVM2 performance when a snapshot is done.

Write speed on the Original volume is very bad when a snaphot is active...


For exemple:


Speed on /dev/vg0/test when there is NO snapshot :


suse2:~ # dd if=/dev/zero of=/dev/vg0/test bs=2M count=400

400+0 records in

400+0 records out

838860800 bytes (839 MB) copied, 6.42741 seconds, 131 MB/s


Speed on /dev/vg0/test when there is one snapshot of this original volume :


suse2:~ # lvremove --force /dev/vg0/test3.snap

 Logical volume "test3.snap" successfully removed

suse2:~ # dd if=/dev/zero of=/dev/vg0/test bs=2M count=400

400+0 records in

400+0 records out

838860800 bytes (839 MB) copied, 6.42741 seconds, 131 MB/s

suse2:~ # lvcreate -s -L1G -ntest.snap /dev/vg0/test

 Logical volume "test.snap" created

suse2:~ # dd if=/dev/zero of=/dev/vg0/test bs=2M count=400

400+0 records in

400+0 records out

838860800 bytes (839 MB) copied, 204.862 seconds, 4.1 MB/s



Speed on /dev/vg0/test when there is 2 snapshots of this original volume :


suse2:~ # lvcreate -s -L1G -ntest1.snap /dev/vg0/test

 Logical volume "test1.snap" created

suse2:~ # lvcreate -s -L1G -ntest2.snap /dev/vg0/test

 Logical volume "test2.snap" created

suse2:~ # lvremove /dev/vg0/test2.snap

Do you really want to remove active logical volume "test2.snap"? [y/n]: y

 Logical volume "test2.snap" successfully removed

suse2:~ # dd if=/dev/zero of=/dev/vg0/test bs=2M count=400

400+0 records in

400+0 records out

838860800 bytes (839 MB) copied, 270.928 seconds, 3.1 MB/s



Do you know  some elements about tunning performance?,?


Performances are
disastrous when a snaphot is active
Could you give your speed result? and your amelioration??


ps:Results are the same whithout Kernel Xen and whith a kernel more recent (
2.6.24.2)
Cordialement,

MARTINEAU
Antony

Service informatique

Assistant informatique
LIPPI Management
La Fouillouse
16440 Mouthiers sur Boheme
Tel.: 05.45.67.34.35
Courriel:
antony.martineau@lippi.fr
http://www.lippi.fr










Ce message et toutes les pieces jointes sont etablis a l'attention exclusive de ses destinataires et sont strictement confidentiels.
Pour en savoir plus cliquer ici

This message and any attachments are confidential to the ordinary user of the e-mail address to which it was addressed and may also be privileged.
More information


_______________________________________________
linux-lvm mailing list

linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at
http://tldp.org/HOWTO/LVM-HOWTO/
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at
http://tldp.org/HOWTO/LVM-HOWTO/









Ce message et toutes les pieces jointes sont etablis a l'attention exclusive de ses destinataires et sont strictement confidentiels.
Pour en savoir plus cliquer ici

This message and any attachments are confidential to the ordinary user of the e-mail address to which it was addressed and may also be privileged.
More information


_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/


Ce message et toutes les pieces jointes sont etablis a l'attention exclusive de ses destinataires et sont strictement confidentiels. Pour en savoir plus cliquer ici
This message and any attachments are confidential to the ordinary user of the e-mail address to which it was addressed and may also be privileged. More information
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux