[openstack-dev] A simple way to improve nova scheduler
joe.gordon0 at gmail.com
Tue Jul 23 20:17:46 UTC 2013
On Tue, Jul 23, 2013 at 1:09 PM, Boris Pavlovic <boris at pavlovic.me> wrote:
> 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.
> 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
> Best regards,
> Boris Pavlovic
> Mirantis Inc.
> On Tue, Jul 23, 2013 at 11:56 PM, Joe Gordon <joe.gordon0 at gmail.com>wrote:
>> On Jul 23, 2013 3:44 PM, "Ian Wells" <ijw.ubuntu at cack.org.uk> wrote:
>> > > * periodic updates can overwhelm things. Solution: remove unneeded
>> > > most scheduling data only changes when an instance does some state
>> > 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
>> > 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
>> > OpenStack-dev at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev