openstack team mailing list archive
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
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
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