I am struggling with python code profiling in general. It has its own caveats like 100% plus overhead. However, on a host with only nova services (DB on a different host), I see cpu utilization spike up quickly with scale. The DB server is relatively calm and never goes over 20%. On a system which relies on DB to fetch all the data, this should not happen.
I could not find any analysis of nova performance either. Appreciate if someone can point me to one. Thanks, On Tue, Aug 11, 2015 at 3:57 PM, Chris Friesen <chris.frie...@windriver.com> wrote: > Just curious...have you measured this consuming a significant amount of > CPU time? Or is it more a gut feel of "this looks like it might be > expensive"? > > Chris > > > On 08/11/2015 04:51 PM, Sachin Manpathak wrote: > >> Here are a few -- >> instance_get_all_by_filters joins manually with >> instances_fill_metadata -- >> >> https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L1890 >> >> https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L1782 >> >> Almost all instance query functions manually join with instance_metadata. >> >> Another example was compute_node_get_all function which joined >> compute_node, >> services and ip tables. But it is simplified in current codebase (I am >> working >> on Juno) >> >> >> >> >> On Tue, Aug 11, 2015 at 3:09 PM, Clint Byrum <cl...@fewbar.com >> <mailto:cl...@fewbar.com>> wrote: >> >> Excerpts from Sachin Manpathak's message of 2015-08-12 05:40:36 +0800: >> > Hi folks, >> > Nova codebase seems to follow manual joins model where all data >> required by >> > an API is fetched from multiple tables and then joined manually by >> using >> > (in most cases) python dictionary lookups. >> > >> > I was wondering about the basis reasoning for doing so. I usually >> find >> > openstack services to be CPU bound in a medium sized environment and >> > non-trivial utilization seems to be from parts of code which do >> manual >> > joins. >> >> Could you please cite specific examples so we can follow along with >> your >> thinking without having to repeat your analysis? >> >> Thanks! >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
