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. 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.
- It should be able to omit per-process displays. In this mode, it
would be able to skip the walk of every process in /proc.
- It should be able to display all zones, projects, or users. The
display only gives the top (and optionally bottom) consumers today and
makes it useless for displaying activity of all users, projects, or
Whether this information is accessible via proc or someplace under
/system is a question I don't have a good answer for.
The next things on my list after the items listed above are:
- Give performance data per service. A while back process contract
decorations (PSARC/2008/046) were added, which would probably be a big
- There's an increasing number of kernel tasks taken care of in task
queues. My understanding is they don't get charged to any process.
Having a way to observe the impact of these taskq tasks could help
administrators understand the relative impact of things like zfs
crypto and zfs compression.
Dtrace can give the answers above but it shouldn't be that hard for
the end user.
zones-discuss mailing list