[openstack-dev] [nova][scheduler]The database access in the scheduler filters
yunhong.jiang at intel.com
Fri Nov 1 17:31:36 UTC 2013
As Shawn Hartsock pointed out in the reply, I made a stupid error in the calculation. It's in fact 55 access per second, not that big number I calculated.
I thought I graduated from elementary school but seems I'm wrong. Really sorry for the stupid error.
> -----Original Message-----
> From: Russell Bryant [mailto:rbryant at redhat.com]
> Sent: Friday, November 01, 2013 9:18 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [nova][scheduler]The database access in the
> scheduler filters
> On 11/01/2013 09:09 AM, Andrew Laski wrote:
> > 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
> > 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
> > 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.
> There's a lot of discussion happening in two different directions, it
> seems. One group is very interested in improving the scheduler's
> ability to make the best decision possible using various policies.
> Another group is concerned with massive scale and is willing to accept
> "good enough" scheduling to get there.
> I think the filter scheduler is pretty reasonable for the best possible
> decision approach today. There's some stuff that could perform better.
> There's more policy knobs that could be added. There's the cross
> service issue to figure out ... but it's not bad.
> I'm very interested in a new "good enough" scheduler. I liked the idea
> of running a bunch of schedulers that each only look at a subset of your
> infrastructure and pick something that's good enough. I'm interested to
> hear other ideas in the session we have on this topic (rethinking
> scheduler design).
> Of course, you get a lot of the massive scale benefits by going to
> cells, too. If cells is our answer here, I really want to see more
> people stepping up to help with the cells code. There are still some
> feature gaps to fill. We should also be looking at the road to getting
> back to only having one way to deploy nova (cells). Having both cells
> vs non-cells options really isn't ideal long term.
> Russell Bryant
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev