On Tue, Jul 23, 2013 at 1:09 PM, Boris Pavlovic <[email protected]> wrote:
> Ian, > > There are serious scalability and performance problems with DB usage in > current scheduler. > Rapid Updates + Joins makes current solution absolutely not scalable. > > Bleuhost example just shows personally for me just a trivial thing. (It > just won't work) > > We will add tomorrow antother graphic: > Avg user req / sec in current and our approaches. > Will you be releasing your code to generate the results? Without that the graphic isn't very useful > I hope it will help you to better understand situation. > > > Joshua, > > Our current discussion is about could we remove information about compute > nodes from Nova saftly. > Both our and your approach will remove data from nova DB. > > Also your approach had much more: > 1) network load > 2) latency > 3) one more service (memcached) > > So I am not sure that it is better then just send directly to scheduler > information. > > > Best regards, > Boris Pavlovic > --- > Mirantis Inc. > > > > > > > On Tue, Jul 23, 2013 at 11:56 PM, Joe Gordon <[email protected]>wrote: > >> >> On Jul 23, 2013 3:44 PM, "Ian Wells" <[email protected]> wrote: >> > >> > > * periodic updates can overwhelm things. Solution: remove unneeded >> updates, >> > > most scheduling data only changes when an instance does some state >> change. >> > >> > It's not clear that periodic updates do overwhelm things, though. >> > Boris ran the tests. Apparently 10k nodes updating once a minute >> > extend the read query by ~10% (the main problem being the read query >> > is abysmal in the first place). I don't know how much of the rest of >> > the infrastructure was involved in his test, though (RabbitMQ, >> > Conductor). >> >> A great openstack at scale talk, that covers the scheduler >> http://www.bluehost.com/blog/bluehost/bluehost-presents-operational-case-study-at-openstack-summit-2111 >> >> > >> > There are reasonably solid reasons why we would want an alternative to >> > the DB backend, but I'm not sure the update rate is one of them. If >> > we were going for an alternative the obvious candidate to my mind >> > would be something like ZooKeeper (particularly since in some setups >> > it's already a channel between the compute hosts and the control >> > server). >> > -- >> > Ian. >> > >> > _______________________________________________ >> > OpenStack-dev mailing list >> > [email protected] >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
