Re: Discussion: performance issue on event activation mode

On Mon, Oct 18, 2021 at 11:51:27PM +0200, Zdenek Kabelac wrote:
> The more generic solution with auto activation should likely try to 'active'
> as much found complete VGs as it can at any given moment in time.

> ATM lvm2 suffers when it's being running massively parallel - this has not
> been yet fully analyzed - but there is certainly much better throughput if
> there is limitted amount of 'parallel' executed lvm2 commands.

There a couple of possible bottlenecks that we can analyze separately:

1. the bottleneck of processing 100's or 1000's of uevents+pvscans.
2. the bottleneck of large number of concurrent vgchange -aay vgname.

The lvm-activate-vgs services completely avoid 1 by skipping them all, and
it also avoids 2 with one vgchange -aay *.  So, it seems to be pretty
close to an optimal solution, but I am interested to know more precisely
which bottlenecks we're avoiding.

I believe you're suggesting that bottleneck 1 doesn't really exist, and
that we're mainly suffering from 2.  If that's true, then we could
continue to utilize all the uevents+pvsans, and take advantage of them to
optimize the vgchange -aay commands.

That's an interesting idea, and we actually have the capabilities to try
that right now in my latest dev branch.  The commit "hints: new pvs_online
type" will do just that.  It will use the pvs_online files (created by
each uevent+pvscan) to determine which PVs to activate from.

$ pvs
  PV                 VG Fmt  Attr PSize    PFree   
  /dev/mapper/mpatha mm lvm2 a--  <931.01g <931.00g
  /dev/sdc           cd lvm2 a--  <931.01g  931.00g
  /dev/sdd           cd lvm2 a--  <931.01g <931.01g
$ rm /run/lvm/{pvs,vgs}_online/*
$ vgchange -an
  0 logical volume(s) in volume group "cd" now active
  0 logical volume(s) in volume group "mm" now active
$ vgchange -aay
  1 logical volume(s) in volume group "cd" now active
  3 logical volume(s) in volume group "mm" now active
$ vgchange -an
  0 logical volume(s) in volume group "cd" now active
  0 logical volume(s) in volume group "mm" now active
$ pvscan --cache /dev/sdc
  pvscan[929329] PV /dev/sdc online.
$ pvscan --cache /dev/sdd
  pvscan[929330] PV /dev/sdd online.
$ vgchange -aay --config devices/hints=pvs_online
  1 logical volume(s) in volume group "cd" now active
$ pvscan --cache /dev/mapper/mpatha
  pvscan[929338] PV /dev/mapper/mpatha online.
$ vgchange -aay --config devices/hints=pvs_online
  1 logical volume(s) in volume group "cd" now active
  3 logical volume(s) in volume group "mm" now active

vgchange is activating VGs only from the PVs that have been pvscan'ed.  So
if a large volume of uevents+pvscans is not actually a bottleneck, then it
looks like we could use them to optimize the vgchange commands in the
lvm-activate-vgs services.  I'll set up some tests to see how it compares.

Dave

_______________________________________________
linux-lvm mailing list
[email protected]
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/