[Openstack-operators] nova-placement-api tuning

Chris Dent cdent+os at anticdent.org
Thu Mar 29 17:05:43 UTC 2018


On Thu, 29 Mar 2018, iain MacDonnell wrote:

>> placement python stack and kicks out the 401. So this mostly
>> indicates that socket accept is taking forever.
>
> Well, this test connects and gets a 400 immediately:
>
> echo | nc -v apihost 8778
>
> so I don't think it's at at the socket level, but, I assume, the actual WSGI 
> app, once the socket connection is established. I did try to choose a test 
> that tickles the app, but doesn't "get too deep", as you say.

Sorry I was being terribly non-specific. I meant generically
somewhere along the way from the either the TCP socket that is
accept the initial http connection to 8778 or the unix domain socket
that is between apache2 and the wsgi daemon process. As you've
discerned, the TCP socket and apache2 are fine.

> Good question. I could have sworn it was in the installation guide, but I 
> can't find it now. It must have come from RDO, i.e.:
>
> https://github.com/rdo-packages/nova-distgit/blob/rpm-master/nova-placement-api.conf

Ooph. I'll see if I can find someone to talk to about that.

> Right, that was my basic assessment too.... so now I'm trying to figure out 
> how it should be tuned, but had not been able to find any guidelines, so 
> thought of asking here. You've confirmed that I'm on the right track (or at 
> least "a" right track).

The mod wsgi docs have a fair bit of stuff about tuning in them, but
it is mixed in amongst various things, but
http://modwsgi.readthedocs.io/en/develop/user-guides/processes-and-threading.html
might be a good starting point.

>>> Other suggestions? I'm looking at things like turning off 
>>> scheduler_tracks_instance_changes, since affinity scheduling is not needed 
>>> (at least so-far), but not sure that that will help with placement load 
>>> (seems like it might, though?)
>> 
>> This won't impact the placement service itself.
>
> It seemed like it might be causing the compute nodes to make calls to update 
> allocations, so I was thinking it might reduce the load a bit, but I didn't 
> confirm that. This was "clutching at straws" - hopefully I won't need to now.

There's duplication of instance state going to both placement and
the nova-scheduler. The number of calls from nova-compute to
placement reduces a bit as you updgrade to newer releases. It's
still more than we'd prefer.


-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent


More information about the OpenStack-operators mailing list