WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Subject: Re: [Xen-devel] xend / xenstored performance & scalability issues
From: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Date: Thu, 12 Oct 2006 16:04:16 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 12 Oct 2006 08:04:40 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20061012141638.GA6878@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20061012141638.GA6878@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Thu, Oct 12, 2006 at 03:16:38PM +0100, Daniel P. Berrange wrote:

> I've been trying to track down just why talking to XenD is resulting in so
> much CPU time being comsumed by both xend & xenstored. As a test case, I'm
> running 'virsh dominfo demo'  which results in a single HTTP request to
> Xend to fetch domain info, eg 'GET /xend/domains/demo'
>
> [Snip]
>
>   2. Why does XenD create sooo many transactions in XenStored for a read op ?
>      Having instrumented Xend it sems that the root cause of the problem is 
> the
>      xen.xend.xenstore.xstransact  class. This alllows one to start a 
> transaction,
>      do a bunch of reads/writes & then commit the transaction. At the same 
> time
>      though it has a bunch of static 'convenience' methods for read & write 
> which
>      will implicitly start & commit a transaction. Well 90% of the code in 
> XenD
>      seems to be using these 'convenience' methods instead of explicitly 
> starting
>      a transaction to cover a piece of work - the result is a simple GET 
> causes
>      16 transactions ....and an 'xm create' results in 80 transactions. These
>      convenience methods are utterly destroying performance.
> 
> Clearly we can't address these for 3.0.3, but I think both of these areas need
> serious work in 3.0.4 if we want a scalable control plane in Dom0. Fixing
> the XenD bit looks particularly hard because any single method using the
> convenience xenstored read functions can be called under many different
> contexts, so of which needs transactions, others which don't. It ought to
> be possible to trace back all the calls & make it possible to pass explicit
> xstransct objects into all calls & then kill off the convenience methods.

Yes, we've already committed to fixing this in Xen 3.0.4.  The Xen-API preview
tree already has this work underway.

Ewan.

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

<Prev in Thread] Current Thread [Next in Thread>