On 3/29/2012 12:46 PM, Justin Santa Barbara wrote:
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.
Well, in a project with the style of fixed-date release (short-duration
train-model) that openstack has, I think we have to accept that there
will never be time to do anything except fight critical bugs "at the
end". At least not until the project code is much more mature. In
projects I have managed we always allocated time at the *beginning* of a
release cycle for fixing some backlogged bugs and performance work.
There is less pressure and the code is not yet churning. It is also
important to have performance benchmark tests to make sure new features
do not introduce performance regressions.
-David
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
