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.ji...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
