All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Pim van Riezen <pi+lists@panelsix.com>
Cc: Xen-devel <xen-devel@lists.xensource.com>
Subject: Re: Working around xenstored performance?
Date: Thu, 31 Jul 2008 10:15:40 +0100	[thread overview]
Message-ID: <20080731091540.GI23888@redhat.com> (raw)
In-Reply-To: <32D4D094-35A8-4972-AAAD-9D86BDB85C0A@panelsix.com>

On Thu, Jul 31, 2008 at 10:41:15AM +0200, Pim van Riezen wrote:
> Good Day,
> 
> For monitoring purposes, we have a process that sends a 'xend.domains'  
> methodCall to xend at timed intervals. Our problem here is that this  
> call, if the extra parameter is not '0', is pretty slow; xenstored  
> will run with 40% cpu grinding over its database before coming up with  
> a reply, hardly something you want to do like every 15 seconds. With  
> the parameter on 0, the response is instantaneous, but lacks any  
> information beyond the list of currently running guests.
> 
> Is there a less intrusive way to just get the cpu-counter for a  
> specific guest through /proc/xen or some such? I'd also be perfectly  
> happy to fish the information out of xenstored's tdb-file, but all of  
> its records seem to be in an undocumented binary encoding so that's  
> not really helping either.

The quickest workaround is to mount /var/lib/xenstore on tmpfs at boot
time. This should reduce overhead by something like ~50%.

> Our set-up is the Fedora branch of 3.0 (but from what I can read, 3.1  
> still has this problem).

If you use libvirt, then once you have fetched a 'virDomainPtr' object,
you can query the CPU / memory utilization of the guest without it
ever hitting xenstore/xend again. The virDomainGetInfo() method is
optimized so it will either make a direct hypercall (very fast), or
if non-root use a setuid proxy to make the hypercall (fairly fast).

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

      parent reply	other threads:[~2008-07-31  9:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-31  8:41 Working around xenstored performance? Pim van Riezen
2008-07-31  8:43 ` Keir Fraser
2008-07-31  9:15 ` Daniel P. Berrange [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080731091540.GI23888@redhat.com \
    --to=berrange@redhat.com \
    --cc=pi+lists@panelsix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.