Aha, right after replied Harsock's mail, I realized I'm correct still. Glad that I did graduated from the school :)
--jyh > -----Original Message----- > From: Jiang, Yunhong [mailto:yunhong.ji...@intel.com] > Sent: Friday, November 01, 2013 10:32 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [nova][scheduler]The database access in the > scheduler filters > > 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. > > --jyh > > > -----Original Message----- > > From: Russell Bryant [mailto:rbry...@redhat.com] > > Sent: Friday, November 01, 2013 9:18 AM > > To: openstack-dev@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 > > 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. > > > > Agreed. > > > > 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@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
