Open Stack

On 11/01/13 at 10:16am, John Garbutt wrote:
>Its intentional. Cells is there to split up your nodes into more
>manageable chunks.

I don't think you mean to say that there's intentionally a performance 
issue.  But yes there are performance issues with the filter scheduler.  

Because I work on a deployment that uses cells to partition the workload 
I haven't seen them myself, but there are plenty of reports from others 
who have encountered them.  And it's easy to run some back of the napkin 
calculations like was done below and see that scheduling will require a 
lot of resources if there's no partitioning.

>
>There are quite a few design summit sessions on looking into
>alternative approaches to our current scheduler.
>
>While I would love a single scheduler to make everyone happy, I am
>thinking we might end up with several scheduler, each with slightly
>different properties, and you pick one depending on what you want to
>do with your cloud.

+1.  We have the ability to drop in different schedulers right now, but 
there's only one really useful scheduler in the tree.  There has been 
talk of making a more performant scheduler which schedules in a 'good 
enough' fashion through some approximation algorithm.  I would love to 
see that get introduced as another scheduler and not as a rework of the 
filter scheduler.  I suppose the chance scheduler could technically 
count for that, but I'm under the impression that it isn't used beyond 
testing.

>
>John
>
>On 31 October 2013 22:39, Jiang, Yunhong <yunhong.jiang at intel.com> wrote:
>> I noticed several filters (AggregateMultiTenancyIsoaltion, ram_filter, type_filter, AggregateInstanceExtraSpecsFilter) have DB access in the host_passes(). Some will even access for each invocation.
>>
>> Just curios if this is considered a performance issue? With a 10k nodes, 60 VM per node, and 3 hours VM life cycle cloud, it will have more than 1 million DB access per second. Not a small number IMHO.
>>
>> Thanks
>> --jyh
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev