On Sun, Nov 16, 2008 at 10:58 PM, Mike Gerdts <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 16, 2008 at 7:40 PM, Jeff Victor <[EMAIL PROTECTED]> wrote:
>> 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.
> zonestat shouldn't be needed to give this information.
Of course. I guess I wasn't clear. I was trying to say "the clearest
example of a kstat that is needed is a kstat, per zone... That kstat
could then be used by many *stat tools, including zonestat, prstat,
> Per zone, project, and user data should be available that allows prstat to
> display this information. When I use prstat -mz or prstat -ma, I
> would expect the collected microstate accounting data would be used to
> populate the display. Other fine points about this include:
> - Currently prstat shows time decayed summaries in the bottom panel, even
> when microstate data is displayed at the top. Time decayed data
> is confusing, particularly when trying to correlate application events that
> last just several seconds to CPU consumption.
Not only is it confusing, it can be very wrong, e.g. if there are many
short-lived processes that come and go between the snapshots that
prstat takes. That's why a kstat like the one described above is
zones-discuss mailing list