Rui, you still can run multiple nova-scheduler process now. 2015-03-05 10:55 GMT+08:00 Rui Chen <[email protected]>:
> Looks like it's a complicated problem, and nova-scheduler can't scale-out > horizontally in active/active mode. > > Maybe we should illustrate the problem in the HA docs. > > http://docs.openstack.org/high-availability-guide/content/_schedulers.html > > Thanks for everybody's attention. > > 2015-03-05 5:38 GMT+08:00 Mike Bayer <[email protected]>: > >> >> >> Attila Fazekas <[email protected]> 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 ? >> >> An upcoming feature in SQLAlchemy 1.0 will remove the vast majority of CPU >> overhead from the query side of SQLAlchemy ORM by caching all the work >> done >> up until the SQL is emitted, including all the function overhead of >> building >> up the Query object, producing a core select() object internally from the >> Query, working out a large part of the object fetch strategies, and >> finally >> the string compilation of the select() into a string as well as organizing >> the typing information for result columns. With a query that is >> constructed >> using the “Baked” feature, all of these steps are cached in memory and >> held >> persistently; the same query can then be re-used at which point all of >> these >> steps are skipped. The system produces the cache key based on the in-place >> construction of the Query using lambdas so no major changes to code >> structure are needed; just the way the Query modifications are performed >> needs to be preceded with “lambda q:”, essentially. >> >> With this approach, the traditional session.query(Model) approach can go >> from start to SQL being emitted with an order of magnitude less function >> calls. On the fetch side, fetching individual columns instead of full >> entities has always been an option with ORM and is about the same speed >> as a >> Core fetch of rows. So using ORM with minimal changes to existing ORM code >> you can get performance even better than you’d get using Core directly, >> since caching of the string compilation is also added. >> >> On the persist side, the new bulk insert / update features provide a >> bridge >> from ORM-mapped objects to bulk inserts/updates without any unit of work >> sorting going on. ORM mapped objects are still more expensive to use in >> that >> instantiation and state change is still more expensive, but bulk >> insert/update accepts dictionaries as well, which again is competitive >> with >> a straight Core insert. >> >> Both of these features are completed in the master branch, the “baked >> query” >> feature just needs documentation, and I’m basically two or three tickets >> away from beta releases of 1.0. The “Baked” feature itself lives as an >> extension and if we really wanted, I could backport it into oslo.db as >> well >> so that it works against 0.9. >> >> So I’d ask that folks please hold off on any kind of migration from ORM to >> Core for performance reasons. I’ve spent the past several months adding >> features directly to SQLAlchemy that allow an ORM-based app to have routes >> to operations that perform just as fast as that of Core without a rewrite >> of >> code. >> >> > 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 ? >> > >> > 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) >> > >> > The opposite way would be to move most operation into the DB side, >> > since the DB already knows everything. >> > (stored procedures ?) >> > >> > Best Regards, >> > Attila >> > >> > >> > ----- Original Message ----- >> >> From: "Rui Chen" <[email protected]> >> >> To: "OpenStack Development Mailing List (not for usage questions)" < >> [email protected]> >> >> 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: >> [email protected]?subject:unsubscribe >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> [email protected]?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
