Xen 
 
Home About Xen.org Xen Xen Summit Wiki Mailing List Bug Tracker Xen Downloads
 
   
 

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>