[libvirt] [PATCH 0/4] improve virConnectListAllInterfaces()

[Daniel P. Berrange]

On Fri, Sep 25, 2015 at 05:22:30PM +0100, Daniel P. Berrange wrote:
> On Fri, Sep 25, 2015 at 11:13:52AM -0400, Laine Stump wrote:
> > There's a bit of background about this here:
> > 
> > https://www.redhat.com/archives/augeas-devel/2015-September/msg00001.html
> > 
> > In short, virt-manager is calling the virInterface APIs and that ties
> > up a libvirt thread (and CPU core) for a very long time on hosts that
> > have a large number of interfaces. These patches don't cure the
> > problem (I don't know that there really is a cure other than "Don't DO
> > that!"), but they do fix a couple of bugs I found while investigating,
> > and make a substantial improvement in the amount of time used by
> > virConnectListAllInterfaces().
> > 
> > One thing that I wondered about while investigating this - a big use
> > of CPU by virConnectListAllInterfaces() comes from the need to
> > retrieve the MAC address of every interface. The MAC addresses are
> > both
> > 
> > 1) returned to the caller in the interface objects and
> > 
> > 2) sent to the policykit ACL checking to decide which interfaces to include in
> > the list.
> > 
> > I'm 90% confident that
> > 
> > 1) most callers don't really care that they're getting the MAC address
> > along with interface name (virt-manager, for example, follows up with
> > a virInterfaceGetXMLDesc() anyway)), and
> > 
> > 2) there is not even a single host *anywhere* that is using libvirt
> > policykit ACLs to limit the list of host interfaces viewable by a
> > client.
> > 
> > So we could add a flag to not return MAC addresses, which would allow
> > cutting down the time to list all devices to something < 1
> > second). But this would be at the expense of no longer having the
> > possibility to limit the list with policykit according to MAC
> > address. Since all host interface information is available to all
> > users via the file system, for example, I don't see this as a huge
> > issue, but it would change behavior, so I don't feel comfortable doing
> > it. I don't like the idea of a single API call taking > 1 minute to
> > return either, though. Does anyone have an opinion about this?
> 
> Ultimately 500 interfaces, each ifcfg-XXX file 300 bytes in size
> on average is only 150 KB of data. Given the amount of data we
> are consuming, here I think it is reasonable to expect we can
> process than in a tiny fraction of a second. So there's clearly
> a serious algorithmic / data structure flaw here if its taking
> minutes.
> 
> By the sounds of the thread you quote, its in augeas itself, so I
> think we really need to focus on addressing that root cause as a
> priority rather than try to work around it.
> 
> As a side note, we might consider adding new API to netcf so that
> we can fetch the entire interface set + macs in one api call to
> netcf, though I doubt it'd chance performance that much.

So, I instrumented the netcf and augeas code to checking timings.

The aug_get calls time less than a millisecond, as do the various
other calls. I found the bulk of the time is actually coming from
the netcf function "get_augeas", which in turns call "aug_load"
for every single damn netcf function call. So when we have 500
interfaces, we're telling augeas to load all the config files
1000 times. That's where the slowness is coming from....

Either we need to stop loading congfig files on every fnuction
call in netcf, or we need to add a netcf bulk data API call,
so that libvirt can load /all/ the data it needs in 1 single
API call.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|