[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] xend / xenstored performance & scalability issues


  • To: "Daniel P. Berrange" <berrange@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Thu, 12 Oct 2006 15:33:28 +0100
  • Delivery-date: Thu, 12 Oct 2006 07:34:43 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcbuC2HUoKLXZFn+EduoyQAX8io7RQ==
  • Thread-topic: [Xen-devel] xend / xenstored performance & scalability issues

On 12/10/06 15:16, "Daniel P. Berrange" <berrange@xxxxxxxxxx> 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.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.