← Back to team overview

openstack team mailing list archive

Re: Performance diagnosis of metadata query


> Is there a good way to map back where in the code these calls are coming
> from?

There's not a great way currently.  I'm trying to get a patch in for Essex
which will let deployments easily turn on SQL debugging (though this is
proving contentious); it will have a configurable log level to allow for
future improvements, and one of the things I'd like to do is add later is
something like a stack trace on 'problematic' SQL (large row count, long
query time).  But that'll be in Folsom, or in G if we don't get logging
into Essex.

In the meantime, it's probably not too hard to follow the code and infer
where the calls are coming from.  In the full log, there's a bit more
context, and I've probably snipped some of that out; in this case the
relevant code is get_metadata in the compute API service and
get_instance_nw_info in the network service.

>  Regardless, large table scans should be eliminated, especially if the
> table is mostly read, as the hit on an extra index on insert will be
> completely offset by the speedups on select.

Agreed - some of these problems are very clear-cut!

It does frustrate me that we've done so much programming work, but then not
do the simple stuff at the end to make things work well.  It feels a bit
like shipping we're shipping C code which we've compiled with -O0 instead
of -O3.

Follow ups