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
