<div dir="ltr">My BP aims is launching multiple nova-scheduler processes on a host, like nova-conductor.<div><br><div>If we run multiple nova-scheduler services on separate hosts, that will work, forking the multiple nova-scheduler</div><div>child processes on a host that will work too? Different child processes had different HostState object in self memory, </div><div>the only different point with HA is just launching all scheduler processes on a host.</div><div><br></div></div><div>I'm sorry to waste some time, I just want to clarify it.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-03-05 17:12 GMT+08:00 Sylvain Bauza <span dir="ltr"><<a href="mailto:sbauza@redhat.com" target="_blank">sbauza@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<br>
<div>Le 05/03/2015 08:54, Rui Chen a écrit :<br>
</div><span class="">
<blockquote type="cite">
<div dir="ltr">We will face the same issue in multiple
nova-scheduler process case, like Sylvain say, right?
<div><br>
</div>
<div><span style="font-size:14px">Two processes/workers can
actually consume two distinct resources on the same
HostState.</span></div>
<div><br>
</div>
</div>
</blockquote>
<br></span>
No. The problem I mentioned was related to having multiple threads
accessing the same object in memory.<br>
By running multiple schedulers on different hosts and listening to
the same RPC topic, it would work - with some caveats about race
conditions too, but that's unrelated to your proposal -<br>
<br>
If you want to run multiple nova-scheduler services, then just fire
them up on separate machines (that's HA, eh) and that will work.<span class="HOEnZb"><font color="#888888"><br>
<br>
-Sylvain</font></span><div><div class="h5"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
<div>
<table style="font-size:14px" cellpadding="0">
<tbody>
<tr>
<td style="width:904px"><br>
</td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2015-03-05 13:26 GMT+08:00 Alex Xu <span dir="ltr"><<a href="mailto:soulxu@gmail.com" target="_blank">soulxu@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">Rui, you still can run multiple
nova-scheduler process now.
<div>
<div><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>
<div>
<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>
</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>
<br>
<fieldset></fieldset>
<br>
<pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<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>
</pre>
</blockquote>
<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>