<div dir="ltr">Rui, you still can run multiple nova-scheduler process now.<br><div class="gmail_extra"><br><div class="gmail_quote">2015-03-05 10:55 GMT+08:00 Rui Chen <span dir="ltr"><<a href="mailto:chenrui.momo@gmail.com" target="_blank">chenrui.momo@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Looks like it's a complicated problem, and nova-scheduler can't scale-out horizontally in active/active mode.<div><br></div><div>Maybe we should illustrate the problem in the HA docs.</div><div><br></div><div><a href="http://docs.openstack.org/high-availability-guide/content/_schedulers.html" target="_blank">http://docs.openstack.org/high-availability-guide/content/_schedulers.html</a></div><div><div><br><div>Thanks for everybody's attention.</div></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2015-03-05 5:38 GMT+08:00 Mike Bayer <span dir="ltr"><<a href="mailto:mbayer@redhat.com" target="_blank">mbayer@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
<br>
Attila Fazekas <<a href="mailto:afazekas@redhat.com" target="_blank">afazekas@redhat.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> I wonder what is the planned future of the scheduling.<br>
><br>
> The scheduler does a lot of high field number query,<br>
> which is CPU expensive when you are using sqlalchemy-orm.<br>
> Does anyone tried to switch those operations to sqlalchemy-core ?<br>
<br>
</span>An upcoming feature in SQLAlchemy 1.0 will remove the vast majority of CPU<br>
overhead from the query side of SQLAlchemy ORM by caching all the work done<br>
up until the SQL is emitted, including all the function overhead of building<br>
up the Query object, producing a core select() object internally from the<br>
Query, working out a large part of the object fetch strategies, and finally<br>
the string compilation of the select() into a string as well as organizing<br>
the typing information for result columns. With a query that is constructed<br>
using the “Baked” feature, all of these steps are cached in memory and held<br>
persistently; the same query can then be re-used at which point all of these<br>
steps are skipped. The system produces the cache key based on the in-place<br>
construction of the Query using lambdas so no major changes to code<br>
structure are needed; just the way the Query modifications are performed<br>
needs to be preceded with “lambda q:”, essentially.<br>
<br>
With this approach, the traditional session.query(Model) approach can go<br>
from start to SQL being emitted with an order of magnitude less function<br>
calls. On the fetch side, fetching individual columns instead of full<br>
entities has always been an option with ORM and is about the same speed as a<br>
Core fetch of rows. So using ORM with minimal changes to existing ORM code<br>
you can get performance even better than you’d get using Core directly,<br>
since caching of the string compilation is also added.<br>
<br>
On the persist side, the new bulk insert / update features provide a bridge<br>
from ORM-mapped objects to bulk inserts/updates without any unit of work<br>
sorting going on. ORM mapped objects are still more expensive to use in that<br>
instantiation and state change is still more expensive, but bulk<br>
insert/update accepts dictionaries as well, which again is competitive with<br>
a straight Core insert.<br>
<br>
Both of these features are completed in the master branch, the “baked query”<br>
feature just needs documentation, and I’m basically two or three tickets<br>
away from beta releases of 1.0. The “Baked” feature itself lives as an<br>
extension and if we really wanted, I could backport it into oslo.db as well<br>
so that it works against 0.9.<br>
<br>
So I’d ask that folks please hold off on any kind of migration from ORM to<br>
Core for performance reasons. I’ve spent the past several months adding<br>
features directly to SQLAlchemy that allow an ORM-based app to have routes<br>
to operations that perform just as fast as that of Core without a rewrite of<br>
code.<br>
<div><div><br>
> The scheduler does lot of thing in the application, like filtering<br>
> what can be done on the DB level more efficiently. Why it is not done<br>
> on the DB side ?<br>
><br>
> There are use cases when the scheduler would need to know even more data,<br>
> Is there a plan for keeping `everything` in all schedulers process memory up-to-date ?<br>
> (Maybe zookeeper)<br>
><br>
> The opposite way would be to move most operation into the DB side,<br>
> since the DB already knows everything.<br>
> (stored procedures ?)<br>
><br>
> Best Regards,<br>
> Attila<br>
><br>
><br>
> ----- Original Message -----<br>
>> From: "Rui Chen" <<a href="mailto:chenrui.momo@gmail.com" target="_blank">chenrui.momo@gmail.com</a>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
>> Sent: Wednesday, March 4, 2015 4:51:07 AM<br>
>> Subject: [openstack-dev] [nova] blueprint about multiple workers supported   in nova-scheduler<br>
>><br>
>> Hi all,<br>
>><br>
>> I want to make it easy to launch a bunch of scheduler processes on a host,<br>
>> multiple scheduler workers will make use of multiple processors of host and<br>
>> enhance the performance of nova-scheduler.<br>
>><br>
>> I had registered a blueprint and commit a patch to implement it.<br>
>> <a href="https://blueprints.launchpad.net/nova/+spec/scheduler-multiple-workers-support" target="_blank">https://blueprints.launchpad.net/nova/+spec/scheduler-multiple-workers-support</a><br>
>><br>
>> This patch had applied in our performance environment and pass some test<br>
>> cases, like: concurrent booting multiple instances, currently we didn't find<br>
>> inconsistent issue.<br>
>><br>
>> IMO, nova-scheduler should been scaled horizontally on easily way, the<br>
>> multiple workers should been supported as an out of box feature.<br>
>><br>
>> Please feel free to discuss this feature, thanks.<br>
>><br>
>> Best Regards<br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>