Open Stack

>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120329/f3f5a8eb/attachment.html>