On 11/18/2015 09:44 AM, Richard W.M. Jones wrote: > On Wed, Nov 18, 2015 at 01:04:32PM +0000, 张强 wrote: >> Hi all, >> I’m studying the source code, and I saw this in domain.py around line 164: >> … >> curmem = stats['rss'] >> totalmem = stats['actual'] >> except libvirt.libvirtError, err: >> logging.error("Error reading mem stats: %s", err) >> >> pcentCurrMem = curmem * 100.0 / totalmem >> pcentCurrMem = max(0.0, min(pcentCurrMem, 100.0)) >> … >> >> But using this algorithm, I’m always getting results that are greater than 100: >>>>> dom.memoryStats() >> {'actual': 16777216L, 'rss': 17062900L} >> >> 17062900 * 100 / 16777216 = 101.7028… >> >> Is this normal? > > The VIR_DOMAIN_MEMORY_STAT_RSS statistic returned for qemu/KVM guests > is the resident set size (RSS) of the qemu process. Of course that > includes all the overhead of qemu, such as host-side structures used > when emulating devices. Plus the guest RAM, which is just a regular > malloc-style allocation inside qemu and so also contributes to the RSS. > > The 'actual' field seems to come from the libvirt > VIR_DOMAIN_MEMORY_STAT_ACTUAL_BALLOON statistic which is found by > sending the query-balloon monitor command to the guest. The returned > value is the guest's get_current_ram_size() (or less if the balloon is > "inflated", but for the majority of guests the balloon is never used). > > Given all that, it seems reasonable that rss > actual, and so you'd > get a number > 100%. Sometimes. It also seems to me that if the > guest RAM had been allocated but not accessed, you might see rss < actual. > > rss / actual seems like a fairly meaningless number from a > virt-manager point of view. > Yeah I think this calculation is leftover from when virt-manager's memory reporting just tracked memory ballooning, so pcentCurrMem was <currentMemory> / <memory>. I'll look into cleaning it up - Cole _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list