Open Stack

As far as the send only when you have to. That reminds me of this piece of work that could be resurrected that slowed down the periodic updates when nothing was changing.

https://review.openstack.org/#/c/26291/

Could be brought back, the concept still feels useful imho. But maybe not to others :-P

From: Boris Pavlovic <boris at pavlovic.me<mailto:boris at pavlovic.me>>
Reply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Wednesday, July 24, 2013 12:12 PM
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] A simple way to improve nova scheduler

Hi Mike,


On Wed, Jul 24, 2013 at 1:01 AM, Mike Wilson <geekinutah at gmail.com<mailto:geekinutah at gmail.com>> wrote:
Again I can only speak for qpid, but it's not really a big load on the qpidd server itself. I think the issue is that the updates come in serially into each scheduler that you have running. We don't process those quickly enough for it to do any good, which is why the lookup from db. You can see this for yourself using the fake hypervisor, launch yourself a bunch of simulated nova-compute, launch a nova-scheduler on the same host and even with 1k or so you will notice the latency between the update being sent and the update actually meaning anything for the scheduler.

I think a few points that have been brought up could mitigate this quite a bit. My personal view is the following:

-Only update when you have to (ie. 10k nodes all sending update every periodic interval is heavy, only send when you have to)
-Don't fanout to schedulers, update a single scheduler which in turn updates a shared store that is fast such as memcache

I guess that effectively is what you are proposing with the added twist of the shared store.


Absolutely agree with this. Especially with using memcached (or redis) as common storage for all schedulers.

Best regards,
Boris Pavlovic
---
Mirantis Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130724/0deba249/attachment.html>