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

Re: [Libvir] Question on acquiring cpuTime in struct _virDomainInfo



Hi Daniel,

first I'd like to thank you for your speedy answer and the suggested solution. But I think it doesn't fit to my problem. The program I write is a sensor, which is executed by a given time intervall. So I'm not able to cache the domain handles.

But that rises another question in my mind. Till now I assumed that I have to get a new domain handle to receive updated information (cpuTime) from the domain, do I? Else I could avoid a second call to get a second domain handle.

Cheers,

	Jan

On 23.05.2007, at 15:30, Daniel P. Berrange wrote:
On Wed, May 23, 2007 at 02:35:47PM +0200, Jan Michael wrote:
In the described stress situation it tooks about an average of 4
seconds to make the following to function calls, which provide me the
cpuTime of a domain

dom_old = virDomainLookupByID(conn_old, listOfDomains [i]);
	    ret = virDomainGetInfo(dom_old, &info_old);

It is the virDomainLookupByID call which is killing your performance
here  - it has to go to XenD, and XenD does *incredibly* stupid stuff
talking to xenstored

http://lists.xensource.com/archives/html/xen-devel/2007-04/ msg00663.html

So each call takes ~1 second under normal conditions, so 4 seconds
isn't surprising under high load.

This is one of the reasons why the Xen driver in libvirt tries to talk
directly to the hypervisor if at all possible - the HV impl of most
calls is at least x1000 faster than the XenD impl. virConnectListDomains & virDomainGetInfo both have impls which talk to the HV so they are very
fast to execute. The virDomainLookupByID has no HV impl, since we need
to talk to XenD to find the guests name & UUID info.

Here are the stats from my latest measurement:

		old cpuTime		new cpuTime

Domain-0:	3s 4294835190ms		3s 4294849513ms
stornode:	5s 580501ms 		6s 4294550691ms
worknode:	6s 4294546809ms		5s 582761ms

That leads to results in cpu utilisation computation for the node,
which are much lower, around 75%, than the real value (100%) would be.

One solution would be to add the measured time make those calls to
used cpuTime. But this in turn can cause calculations of to high
values because I don't really know in which point in time the value
is written to the structure.

The approach I'd recommend is to make sure you avoid calling virDomainLookupByID.
If you've got a simple loop like pseduo-code...

     forever() {
         ids = virConnectListDomains()
         foreach (id in ids) {
            dom = virDomainLookupByID(id)
            info = virDomainGetInfo(dom)
         }
     }

Then, you need to pull the virDomainLookupByID out of the inner loop.
Basically cache the 'virDomainPtr' handles - you can detect new domains, or shutdown domains after each call to virConnectListDomains(). So with correct caching of handles, you should only need to suffer the performance
hit from virDomainLookupByID once per guest - the first time it starts

Nevertheless is xentop showing me every time the correct cpu-
utilisation of each of my domains. So that I conclude, that this
problem must have something to do with libvirt API.

Its just libvirt exposing the undering inadequacies of XenD & XenStoreD
impl & performance :-(

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


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