OK, so I'm getting deja-vu from 15 years ago when we had exactly the same frustrations and Rich Pettit and I created the SE toolkit to act as a buffer between the particular set of kstats etc. that were available in each release, and the "fixed" versions of various xxstat like tools that we wrote. (Yes it was 1993...)
If you get the SE toolkit (which has since been open sourced in sourceforge) and look at the kstat.se file you will find #if #else #endif blocks that completely describe the evolution of every kstat (including every network interface) for the last 15 years. Think of it as executable documentation. You will also find a large collection of intermediate data collection definitions that export a stable and easy to use interface to scripts (data in floating point per-second rates etc), and lots of other useful stuff. Here's a few metrics that really need fixing: - separate read and write response times in iostat (like vxstat has...) - collect iostats per file per process - swap -s (see swap.se for what is broken and how to fix it) - make extended system accounting usable (see http://www.orcaware.com/orca/pub/extracct/) Adrian On Fri, Feb 13, 2009 at 10:30 PM, Jason King <ja...@ansipunx.net> wrote: > On Fri, Feb 13, 2009 at 3:45 PM, Dan Price <d...@eng.sun.com> wrote: > > On Fri 13 Feb 2009 at 03:32PM, Jason King wrote: > >> > >> I would like the think that, all the (summarized) 'never use any > >> kstats -- those are private' emails I'm getting off list, as well as > >> past reactions I've seen seem to suggest otherwise (not that I'm > >> really going to let it stop things -- I'd rather have a good tool, > > > > I don't know if you're going to get any one voice which is "Sun" > > here. If I was to attack this problem, I would, as Brendan suggests: > > > > - Create mechanism for expressing kstat metadata, and for > > querying said mechanism. I would expect this, if properly > > architected, to be non-controversial. The DTrace stability > > mechanism was not particularly controversial when ARC > > considered it in the DTrace case. The trick is nailing > > down the different attributes of stability and ancillary > > information needed by the consumer. (Stability of name of > > kstat. Stability of its type. Stability of its semantic > > meaning. Whether said kstat is virtualized for zones or not. > > Maybe others). > > > > - Select kstats to raise above "private" and run ARC cases to > > promote the stability level. This creates a commitment-- > > which in some cases is probably fine, and in some cases > > may not be. > > > > Properly architected, a proposal of this nature would get my support. > > It's not a trivial project, to be sure. > > Let's do it. > > I think the performance and/or observability communites would be > appropriate sponsors (please chime in if anyone disagrees). > > Would we want to be more generic and make the goal a generic > annotation feature to kstats (of which stability attributes would be > one sort of annotation), or stay strictly with stability annotations > (I'm not sure one is any more or less difficult than the other)? > _______________________________________________ > perf-discuss mailing list > perf-discuss@opensolaris.org >
_______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
