On 03/04/2015 01:51 AM, Attila Fazekas wrote:
Hi,

I wonder what is the planned future of the scheduling.

The scheduler does a lot of high field number query,
which is CPU expensive when you are using sqlalchemy-orm.
Does anyone tried to switch those operations to sqlalchemy-core ?

Actually, the scheduler does virtually no SQLAlchemy ORM queries. Almost all database access is serialized from the nova-scheduler through the nova-conductor service via the nova.objects remoting framework.

The scheduler does lot of thing in the application, like filtering
what can be done on the DB level more efficiently. Why it is not done
on the DB side ?

That's a pretty big generalization. Many filters (check out NUMA configuration, host aggregate extra_specs matching, any of the JSON filters, etc) don't lend themselves to SQL column-based sorting and filtering.

There are use cases when the scheduler would need to know even more data,
Is there a plan for keeping `everything` in all schedulers process memory 
up-to-date ?
(Maybe zookeeper)

Zookeeper has nothing to do with scheduling decisions -- only whether or not a compute node's "service descriptor" is active or not. The end goal (after splitting the Nova scheduler out into Gantt hopefully at the start of the L release cycle) is to have the Gantt database be more optimized to contain the resource usage amounts of all resources consumed in the entire cloud, and to use partitioning/sharding to scale the scheduler subsystem, instead of having each scheduler process handle requests for all resources in the cloud (or cell...)

The opposite way would be to move most operation into the DB side,
since the DB already knows everything.
(stored procedures ?)

See above. This assumes that the data the scheduler is iterating over is well-structured and consistent, and that is a false assumption.

Best,
-jay

Best Regards,
Attila


----- Original Message -----
From: "Rui Chen" <chenrui.m...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Sent: Wednesday, March 4, 2015 4:51:07 AM
Subject: [openstack-dev] [nova] blueprint about multiple workers supported      
in nova-scheduler

Hi all,

I want to make it easy to launch a bunch of scheduler processes on a host,
multiple scheduler workers will make use of multiple processors of host and
enhance the performance of nova-scheduler.

I had registered a blueprint and commit a patch to implement it.
https://blueprints.launchpad.net/nova/+spec/scheduler-multiple-workers-support

This patch had applied in our performance environment and pass some test
cases, like: concurrent booting multiple instances, currently we didn't find
inconsistent issue.

IMO, nova-scheduler should been scaled horizontally on easily way, the
multiple workers should been supported as an out of box feature.

Please feel free to discuss this feature, thanks.

Best Regards


__________________________________________________________________________
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

Reply via email to