Open Stack

On Mon, 2013-01-14 at 11:24 +0000, Daniel P. Berrange wrote:
> On Mon, Jan 14, 2013 at 09:55:12PM +1100, Michael Still wrote:
> > On Mon, Jan 14, 2013 at 9:44 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> > 
> > [snip]
> > 
> > > For example in the libvirt driver we use a threadpool for running the
> > > native API calls to avoid blocking eventlet. This doc
> > >
> > >   doc/source/devref/threading.rst
> > >
> > > indicates that DB calls used to do the same thing, but apparently don't
> > > anymore. That said, this may be solved with most of the DB calls being
> > > removed due to nodb-compute blueprint. There could be other areas that
> > > would benefit from a threadpool though
> > 
> > So the current big use case for this is in the libvirt driver. The
> > image cache manager needs to do a lot of file IO, and it locks up the
> > main thread while it does that. If your images are really large, then
> > it locks the world up for a really long time. Now, the initial
> > proposal for that was to put a heap of yields into the code that did
> > the IO, but we didn't like that, so this code started out as a way of
> > exploring how to solve the problem without yielding. It should be
> > noted this all came about at the request of Yahoo! who had performance
> > problems because of this IO load. In fact, I'm pretty sure that the
> > image cache manager is the only "external capable" periodic task at
> > the moment, but I am sure there could be more.
> 
> Looking at the code that is run for the image cache manager, I can't
> help thinking this would easily be handled by a native thread without
> introducing any concurrency/locking problems wrt the rest of the Nova
> libvirt driver. So IMHO this doesn't really justify a new standalone
> service.

Or perhaps even simpler than native threads, have the periodic task
spawn off a new process for the long-running operation and reap it on
the next task iteration.

Cheers,
Mark.