On Mon, Jun 09, 2008 at 12:06:19PM +0200, Antony MARTINEAU wrote: > Thanks for your answer... > But my test show that it is, the LVM2 software the probleme... device-mapper snapshot target actually. > > Because even whith 3 writing test at the same time on 3 LV which are on > the same VG and the same PV, the performance are better than one LV whith > only one snapshot... Sure, the write patterns for snapshots go sequentially to the disk (i.e. read from origin, write to COW store, write to origin, ...). > > Look this test: > > suse2:~ # dd if=/dev/zero of=/dev/vg0/test bs=10M count=150 > 150+0 records in > 150+0 records out > 1572864000 bytes (1.6 GB) copied, 27.9422 seconds, 56.3 MB/s > > suse2:~ # dd if=/dev/zero of=/dev/vg0/test2 bs=10M count=150 > 150+0 records in > 150+0 records out > 1572864000 bytes (1.6 GB) copied, 33.2836 seconds, 47.3 MB/s > > suse2:~ # dd if=/dev/zero of=/dev/vg0/test3 bs=10M count=150 > 150+0 records in > 150+0 records out > 1572864000 bytes (1.6 GB) copied, 33.784 seconds, 46.6 MB/s > > With 3 writing test AT THE SAME TIME , the average is better that one > writing test on one LV whith one snap > > Look, > > suse2:~ # lvcreate -s -L2G -ntest.snap /dev/vg0/test > Logical volume "test.snap" created > > suse2:~ # dd if=/dev/zero of=/dev/vg0/test bs=10M count=150 > 150+0 records in > 150+0 records out > 1572864000 bytes (1.6 GB) copied, 382.315 seconds, 4.1 MB/s > > It is disastrous... > > I think dd is a good test... It's an extreme test like I tried to point out. Like already mentioned: you gotta put the COW store on a seperate PV after adding one to your vg0 (say /dev/sdb1). E.g.: pvcreate /dev/sdb1 vgextend vg0 /dev/sdb1 lvcreate -s -L2G -ntest.snap /dev/vg0/test /dev/sdb1 Heinz > > > 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 : > Heinz Mauelshagen <mauelshagen@redhat.com> > Pour : > LVM general discussion and development <linux-lvm@redhat.com> > Date: > 09/06/2008 11:46 > Objet : > Re: Performance tunning on LVM2 > > > > On Fri, Jun 06, 2008 at 08:03:51AM -0700, Larry Dickson wrote: > > 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? > > If I read correctly, Antony just has *ONE* PV. > > So no matter what, he has to add another to allow for snapshot COW > store allocation on that other PV, distinct from the one holding > the origin(s). Presumably there's no other bottleneck aside from the > disk, that'll do better. > > Keep in mind, that unless you've got streaming writes, the performance > won't drop as much as in the (artificial) dd test below. > > FYI: With the current snapshot implementation, multiple snapshots per > single > origin will throttle write performance because of write duplication > to all per snapshot COW stores. > > Heinz > > > > > 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* <antony.martineau@lippi.fr>* > > > **http://www.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*<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* <http://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* <antony.martineau@lippi.fr>* > > > **http://www.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* <http://www.lippi.fr/disclaimer.php> > > > > > > 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* <http://www.lippi.fr/disclaimer.php> > > > > > > > > > _______________________________________________ > > > linux-lvm mailing list* > > > **linux-lvm@redhat.com* <linux-lvm@redhat.com>* > > > **https://www.redhat.com/mailman/listinfo/linux-lvm*< > https://www.redhat.com/mailman/listinfo/linux-lvm> > > > read the LVM HOW-TO at *http://tldp.org/HOWTO/LVM-HOWTO/*< > 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* <http://www.lippi.fr/disclaimer.php> > > > > > > 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* <http://www.lippi.fr/disclaimer.php> > > > > > > > > > _______________________________________________ > > > 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/ > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > Heinz Mauelshagen Red Hat GmbH > Consulting Development Engineer Am Sonnenhang 11 > Storage Development 56242 Marienrachdorf > Germany > Mauelshagen@RedHat.com PHONE +49 171 7803392 > FAX +49 2626 924446 > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > _______________________________________________ > 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 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Heinz Mauelshagen Red Hat GmbH Consulting Development Engineer Am Sonnenhang 11 Storage Development 56242 Marienrachdorf Germany Mauelshagen@RedHat.com PHONE +49 171 7803392 FAX +49 2626 924446 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _______________________________________________ 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/