<div dir="ltr">Folks,<div><br></div><div>we'll take a look if we have observed this issue during MOS testing on 200 nodes lab. Sadly I do not remember this pattern being seen, although we do not keep lots of the VMs for a long time during the synthetic tests.</div><div><br></div><div>Cheers,</div><div>Dina</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 13, 2015 at 2:34 AM, Joshua Harlow <span dir="ltr"><<a href="mailto:harlowja@fastmail.com" target="_blank">harlowja@fastmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ok, so the following is starting to form:<br>
<br>
<a href="https://etherpad.openstack.org/p/remote-conductor-performance" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/remote-conductor-performance</a><br>
<br>
Hopefully we can get to the bottom of this (especially for clouds that run a large amount of computes in a single cell/only one cell).<div class="HOEnZb"><div class="h5"><br>
<br>
Andrew Laski wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 11/12/15 at 10:53am, Clint Byrum wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Excerpts from Joshua Harlow's message of 2015-11-12 10:35:21 -0800:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Mike Dorman wrote:<br>
> We do have a backlog story to investigate this more deeply, we just<br>
have not had the time to do it yet. For us, it’s been easier/faster<br>
to add more hardware to conductor to get over the hump temporarily.<br>
><br>
> We kind of have that work earmarked for after the Liberty upgrade,<br>
in hopes that maybe it’ll be fixed there.<br>
><br>
> If anybody else has done even some trivial troubleshooting already,<br>
it’d be great to get that info as a starting point. I.e. which<br>
specific calls to conductor are causing the load, etc.<br>
><br>
> Mike<br>
><br>
<br>
+1 I think we in the #openstack-performance channel really need to<br>
investigate this, because it really worries me personally from hearing<br>
many many rumors about how the remote conductor falls over. Please join<br>
there and we can try to work through a plan to figure out what to do<br>
about this situation. It would be great if the nova people also joined<br>
there (because in the end, likely something in nova will need to be<br>
fixed/changed/something else to resolve what appears to be a problem for<br>
many operators).<br>
<br>
</blockquote>
<br>
Falling over is definitely a bad sign. ;)<br>
<br>
The concept of pushing messages over a bus instead of just making local<br>
calls shouldn't result in much extra load. Perhaps we just have too many<br>
layers of unoptimized encapsulation. I have to wonder if something like<br>
protobuf would help.<br>
</blockquote>
<br>
Falling over is also a very broad description and doesn't let us know<br>
what the actual issue is.<br>
<br>
 From my experience the performance concern with conductor has been in<br>
not understanding the ratio of conductor nodes to computes that are<br>
necessary for our usage. Conductor doesn't add much extra load, but it<br>
concentrates it on a smaller number of services. If we ran one conductor<br>
per compute I suspect we would have no performance issues, but that's a<br>
lot of capacity to use for this.<br>
<br>
I am curious what conductor/compute ratios that others are trying to<br>
achieve, given equal hardware types for each, and what are the barriers<br>
to this happening?<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</blockquote>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</blockquote>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><p style="font-size:small;margin:0px;font-family:Helvetica">Best regards,</p><p style="font-size:small;margin:0px;font-family:Helvetica">Dina Belova</p><p style="font-size:small;margin:0px;font-family:Helvetica">Software Engineer</p><p style="font-size:small;margin:0px;font-family:Helvetica">Mirantis Inc.</p></div></div></div>
</div>