<div dir="ltr">Hi,<div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"><br></div></div></div>
<br><div class="gmail_quote">On Thu, Sep 29, 2016 at 11:57 PM, Alex Schultz <span dir="ltr"><<a href="mailto:aschultz@redhat.com" target="_blank">aschultz@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hello all,<br>
<br>
So for many years we've been using either the service defaults<br>
(usually python determined processor count) or the $processorcount<br>
fact from facter in puppet for worker configuration options for the<br>
OpenStack services.  If you are currently using the default values<br>
provided by the puppet modules, you will be affected by this upcoming<br>
change. After much discussion and feedback from deployers, we've<br>
decided to change this to a default value that has a cap on it.  This<br>
is primarily from the feedback when deploying on physical hardware<br>
where processor counts can be 32, 48 or even 512.  These values can<br>
lead to excessive memory consumption or errors due to connection<br>
limits (mysql/rabbit).  As such we've come up with a new fact to that<br>
will be used instead of $processorcount.<br>
<br>
The new fact is called $os_workers[0]. This fact uses the<br>
$processorcount to help weigh in on the number of workers to configure<br>
and won't be less than 2 but is capped at 8.  The $os_workers fact<br>
will use the larger value of either '2' or '# of processors / 4' but<br>
will not exceed 8.  The primary goal of this is to improve the user<br>
experience when people install services using the puppet modules and<br>
without having to tune all of these worker values.  We plan on<br>
implementing this for all modules as part of the Ocata cycle.  This<br>
work will can be tracked using the os_workers-fact[1] gerrit topic.<br>
It should be noted that we have implemented this fact in such a way<br>
that operators are free to override it using an external fact to<br>
provide their own values as well.  If you are currently specifying<br>
your own values for the worker configurations in your manifests then<br>
this change will not affect you.  If you have been relying on the<br>
defaults and wish to continue to use the $processorcount logic, we<br>
would recommend either implementing your own external fact[2] for this<br>
or updating your manifests to provide $::processorcount to the workers<br>
configuration.<br></blockquote><div><br></div>This doesn't help a lot. I saw the case where 8 neutron-servers allocated 6GB of RAM. From OOM perspective, the biggest process was MySQL (or Rabbit) as it doesn't calculate the sum of processes. Instead of killing neutron-server it killed MySQL to release some RAM to node. IMO, I would focus on cgroup limitation for OpenStack services as that will allow the operator to specify some the upper limit of CPU and RAM usage for every service.   </div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
As always we'd love to hear feedback on this and any other issues<br>
people might be facing. We're always available in #puppet-openstack on<br>
freenode or via the mailing lists.<br>
<br>
Thanks,<br>
-Alex<br>
<br>
<br>
[0] <a href="https://review.openstack.org/#/c/375146/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/375146/</a><br>
[1] <a href="https://review.openstack.org/#/q/topic:os_workers-fact" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/q/topic:os_workers-fact</a><br>
[2] <a href="https://docs.puppet.com/facter/3.4/custom_facts.html#external-facts" rel="noreferrer" target="_blank">https://docs.puppet.com/<wbr>facter/3.4/custom_facts.html#<wbr>external-facts</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>
</blockquote></div><br></div></div>