Re: xend / xenstored performance & scalability issues

["Daniel P. Berrange" <berrange@redhat.com>]

On Thu, Oct 12, 2006 at 03:33:28PM +0100, Keir Fraser wrote:
> On 12/10/06 15:16, "Daniel P. Berrange" <berrange@redhat.com> wrote:
> 
> >   1. Why the need for xenstored to be doing any of this I/O in the first
> > place?
> >      If the DB needs to be kept on disk at all, it really needs to have a much
> >      saner update/transactional model to only update bits which actually
> > change,
> >      rather than re-creating the entire DB on every transaction.
> >      But it strikes me that the DB could potentially be kept entirely in
> > memory
> >      removing the disk I/O completely. Sure yyou wouldn't be able to restart
> >      the daemon then, but even today you can't restart xenstored & expect
> > things
> >      to still be working.
> 
> We plan to keep transactional state in memory, and commit to tdb only on
> transaction completion. In which case you'll be able to achieve what you
> describe above by keeping the tdb file in a ramdisk. I suspect that'll turn
> out to be unnecessary and once we keep a persistent handle on a single tdb
> file and only update what has changed, we'll find the buffer cache will work
> quite nicely.

Agreed,that sounds like it ought to be able to significantly reduce overhead
without neccessarily needing to go to a purely memory backed storage.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|