Peter,
Your statements are exactly the reason(s) I wrote this prototype.
Solaris engineering is researching this topic, and at listening as we
type... :-) They are very interested in feedback generated by the use
of this prototype.
Any specific ideas you have regarding kstats you think we need, would
be welcomed on this alias.
To me, the clearest example would be a kstat, per zone, which provides
the total amount of CPU time for all of the processes in each zone,
since the zone booted. This would enable tools like zonestat to
request the datum occasionally, in order to determine CPU time per
quantum of elapsed time.
Look for v1.3 of zonestat later this week. It uses the Perl kstats
module and improves the correctness of zone - pool mappings. Each of
these also reduce the amount of CPU time needed to collect the data it
reports.
On Fri, Nov 14, 2008 at 3:21 PM, Peter Tribble [EMAIL PROTECTED] wrote:
On Mon, Nov 10, 2008 at 1:54 AM, Jeff Victor [EMAIL PROTECTED] wrote:
It has become clear that there is a need to monitor resource consumption of
workloads in zones, and an easy method to compare
consumption to resource controls. In order to understand how a software tool
could fulfill this need, I created an OpenSolaris
project and a prototype to get started. If this sounds interesting, you can
find the project and Perl script at:
http://opensolaris.org/os/project/zonestat/ .
If you have any comments, or suggestions for improvement, please let me know
on this e-mail list or via private e-mail.
That reminds me of a blog entry from a year ago:
http://blogs.sun.com/menno/entry/resource_control_observability_using_kstats
Just looking at zonestat.pl, it perpetrates many of the horrors I'm used to
seeing. That's not a criticism, just additional evidence that we desperately
need better interfaces to make getting some of this information easy. There
are - I think - 11 different binaries you invoke to get the various
bits of information
you need. While some of them could be replaced by inline calls to the Kstat
module, others clearly can't. Yet some of the information could just be stored
in kstats, which would make getting at it much easier.
I think what I'm saying is this: what can zonestat tell us about what
additional
kstats should be kept, and what additional APIs would be useful to make
writing
such utilities easier?
--
--JeffV
___
zones-discuss mailing list
zones-discuss@opensolaris.org
