[Libvir] Question on acquiring cpuTime in struct _virDomainInfo
Jan Michael
jan.michael at cern.ch
Thu May 24 16:38:30 UTC 2007
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 -=|
More information about the libvir-list
mailing list