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

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

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'

Run this in a tight loop & I'll see xenstored taking > 50% CPU, and
XenD taking another 11%

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
              
 2647 root      16   0  6188  840  464 R   52  0.0   0:55.04 xenstored          
               
11600 root      18   0  259m 7568 1516 S   11  0.2   0:04.53 python             
               

Its not surprising that xend is consuming time since we are making many 
requests per second, but for an operation which is only doing reads it
having so much time attributed to xenstored seems very excessive. So I
ran oprofile & collected some data about xenstored:

CPU: AMD64 processors, speed 2211.33 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask 
of 0x00 (No unit mask) count 100000
samples  %        image name               symbol name
347226   45.9445  ext3                     (no symbols)
264664   35.0200  jbd                      (no symbols)
31778     4.2048  libc-2.5.so              memset
10763     1.4241  xenstored                main
8884      1.1755  libc-2.5.so              _int_malloc
7053      0.9332  libc-2.5.so              vfprintf
4264      0.5642  xenstored                initialize_set


So almost 80% of xenstored's CPU time is attributed to ext3 & journalling
modules, suggesting xenstored is doing alot of disk I/O. strace()'ing 
the xenstored process shows the only file it is opening is:

# strace -p 2647 -e trace=open,rename,unlink
Process 2647 attached - interrupt to quit
open("/var/lib/xenstored/tdb.0x62aa80", O_WRONLY|O_CREAT|O_TRUNC, 0640) = 13
open("/var/lib/xenstored/tdb.0x62aa80", O_RDWR) = 15
rename("/var/lib/xenstored/tdb.0x62aa80", "/var/lib/xenstored/tdb") = 0
unlink("/var/lib/xenstored/tdb.0x62aa80") = -1 ENOENT (No such file or 
directory)
open("/var/lib/xenstored/tdb.0x62b2b0", O_WRONLY|O_CREAT|O_TRUNC, 0640) = 13
open("/var/lib/xenstored/tdb.0x62b2b0", O_RDWR) = 14
rename("/var/lib/xenstored/tdb.0x62b2b0", "/var/lib/xenstored/tdb") = 0
unlink("/var/lib/xenstored/tdb.0x62b2b0") = -1 ENOENT (No such file or 
directory)
...

So basically it is repeatedly copying its persistent TBD database over and
over again. The TDB on this system is 128 KB in size and each individual HTTP
GET on /xend/domain/demo  is resulting in 16 copies being made. 

Do the maths - 128 * 16 == 2 MB of reads, and 2 MB of writes - for a single
*read* in XenD. Now if I monitor the status of 20 domains, once per second
that's causing 40 MB of writes & 40 MB of reads every second which is utterly
ridiculous & completely non scalable for enterprise deployment :-(

There's two problems I see here:

  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.

  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.

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  -=| 

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