On 09/20/2016 10:22 AM, Andrew Laski wrote:
> Excellent writeup, thanks. Some comments inline.
> On Tue, Sep 20, 2016, at 09:20 AM, Sean Dague wrote:
>> <snip>
>> Performance Bottlenecks
>> -----------------------
>> * scheduling issues with Ironic - (this is a bug we got through during
>>   the week after the session)
>> * live snapshots actually end up performance issue for people
>> The workarounds config group was not well known, and everyone in the
>> room wished we advertised that a bit more. The solution for snapshot
>> performance is in there.
>> There were also general questions about what scale cells should be
>> considered at.
>> ACTION: we should make sure workarounds are advertised better
>> ACTION: we should have some document about "when cells"?
> This is a difficult question to answer because "it depends." It's akin
> to asking "how many nova-api/nova-conductor processes should I run?"
> Well, what hardware is being used, how much traffic do you get, is it
> bursty or sustained, are instances created and left alone or are they
> torn down regularly, do you prune your database, what version of rabbit
> are you using, etc...
> I would expect the best answer(s) to this question are going to come
> from the operators themselves. What I've seen with cellsv1 is that
> someone will decide for themselves that they should put no more than X
> computes in a cell and that information filters out to other operators.
> That provides a starting point for a new deployment to tune from.

I don't think we need "don't go larger than N nodes" kind of advice. But
we should probably know what kinds of things we expect to be hot spots.
Like mysql load, possibly indicated by system load or high level of db
conflicts. Or rabbit mq load. Or something along those lines.

Basically the things to look out for that indicate your are approaching
a scale point where cells is going to help. That also helps in defining
what kind of scaling issues cells won't help on, which need to be
addressed in other ways (such as optimizations).


Sean Dague

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to