<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 2 February 2017 at 10:08, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 02/02/2017 12:49 PM, Armando M. wrote:<br>
><br>
><br>
> On 2 February 2017 at 08:40, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a><br>
</span><div><div class="gmail-h5">> <mailto:<a href="mailto:sean@dague.net">sean@dague.net</a>>> wrote:<br>
><br>
>     On 02/02/2017 11:16 AM, Matthew Treinish wrote:<br>
>     <snip><br>
>     > <oops, forgot to finish my though><br>
>     ><br>
>     > We definitely aren't saying running a single worker is how we recommend people<br>
>     > run OpenStack by doing this. But it just adds on to the differences between the<br>
>     > gate and what we expect things actually look like.<br>
><br>
>     I'm all for actually getting to the bottom of this, but honestly real<br>
>     memory profiling is needed here. The growth across projects probably<br>
>     means that some common libraries are some part of this. The ever growing<br>
>     requirements list is demonstrative of that. Code reuse is good, but if<br>
>     we are importing much of a library to get access to a couple of<br>
>     functions, we're going to take a bunch of memory weight on that<br>
>     (especially if that library has friendly auto imports in top level<br>
>     __init__.py so we can't get only the parts we want).<br>
><br>
>     Changing the worker count is just shuffling around deck chairs.<br>
><br>
>     I'm not familiar enough with memory profiling tools in python to know<br>
>     the right approach we should take there to get this down to individual<br>
>     libraries / objects that are containing all our memory. Anyone more<br>
>     skilled here able to help lead the way?<br>
><br>
><br>
> From what I hear, the overall consensus on this matter is to determine<br>
> what actually caused the memory consumption bump and how to address it,<br>
> but that's more of a medium to long term action. In fact, to me this is<br>
> one of the top priority matters we should talk about at the imminent PTG.<br>
><br>
> For the time being, and to provide relief to the gate, should we want to<br>
> lock the API_WORKERS to 1? I'll post something for review and see how<br>
> many people shoot it down :)<br>
<br>
</div></div>I don't think we want to do that. It's going to force down the eventlet<br>
API workers to being a single process, and it's not super clear that<br>
eventlet handles backups on the inbound socket well. I honestly would<br>
expect that creates different hard to debug issues, especially with high<br>
chatter rates between services.<br></blockquote><div><br></div><div>I must admit I share your fear, but out of the tests that I have executed so far in [1,2,3], the house didn't burn in a fire. I am looking for other ways to have a substantial memory saving with a relatively quick and dirty fix, but coming up empty handed thus far.</div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/428303/">https://review.openstack.org/#/c/428303/</a></div><div>[2] <a href="https://review.openstack.org/#/c/427919/">https://review.openstack.org/#/c/427919/</a></div><div>[3] <a href="https://review.openstack.org/#/c/427921/">https://review.openstack.org/#/c/427921/</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>