Hi Stan,
----- Original Message -----
> Despite the size of the patch it is conceptually simple. The atop
> command by and large does not depend on anything but simple use of
> printf formatting. Instead it rolls its own so it can more predictably
> do tight fitting of values into a maximum sized field. This patch does
> something similar. It adds a routine valstr that fits values for
> situations like:
> 7.37682e+06, length 7, = 7376820
> 7.37682e+06, length 5, = 738e4
> 3.66211e-05, length 7, = 3.66e-5
> It also adds memstr which does something similar, but specifically for
> memory units:
> 1.23457e+08, length 4 = 117M
> Then it changes every use of put_value to use one of the above.
>
> git://sourceware.org/git/pcpfans.git
> scox/dev 55de60ddb953a42f55f27212bf4c66f6f50ae269
> Stan Cox (1): Improve pmatop value fitting.
>
I've pulled this into dev since it appears to fix some things. I'm
seeing all sorts of issues in pmatop though, list below (shall I go
the bugzilla route or is the email summary at the end here OK?)
Coding stuff first - I noticed dup'd imports on the "re" module, &
when looking closer noticed it was reimplementing the string rstrip
method? So, dropped both imports and used that instead.
BTW, if/when pmatop meets up with recent pcp.pmcc module advances,
which would be lovely, the tight formatting code you've newly added
here could live as MetricGroupPrinter class helper methods, perhaps
(along side LIBPCP.pmNumberStr style formatting as another alternate
helper, maybe) - that'= would help other py tools with these strict
formatting needs you've found here.
I ran pmatop and atop side-by-side to try to get a feel for where
things are up to (see attached). I thought I might have a very new
or old atop version since there were so many differences, but the
one I have is ~5 years old and http://www.atoptool.nl/screenshots.php
suggests it hasn't really changed much in the intervening time.
Anyway, here's the list of differences and buglets I noticed. All
can be seen in the attachment - 80x25 terminal sizes - atop above,
pmatop below, and no command line arguments used.
- terminal displaying light-on-dark everywhere instead of just the
two header lines (curses lib issue?)
- hostname not displayed (pmcd.hostname would be a good source)
- sample date/time and interval reporting quite different
- all of the CPU metrics values are different (comparing to other
tools suggests pmatop is misreporting - dual CPU host here FWIW)
- formatting: the "csw" (context switch) field is too wide
- the csw reported value is significantly different
- formatting: the "intr" (interrupts) field is too wide
- the #exit field is missing? (not sure what this is - processes
that exited in the sample interval, I'd guess?)
- the per-cpu stats for the second CPU come-and-go - for some samples
the line is there for cpu#2, in the attached sample its missing
- MEM: atop makes different cut-over decisions in terms of the M -> G
transition?
- PAG column not there in default atop display? has this come in via
the 'm' key (memory display) accidentally or old atop version here?
- NET: the network metric reported values all differ significantly.
- DSK: left/right alignment for disk names
- and in the bottom-half, per-process section:
- col width differences on SYSCPU
- VGROW header offset oddity
- RUID column is shorter, and mishandles usernames longer than width
(causing offset wierdness for subsequent columns)
- RUID left-aligned vs centre-aligned?
- %CPU column grossly incorrect in pmatop (atop looks right) - which
is a good thing, else pmatop would be consuming 66% ;)
- we're reporting kernel threads where pmatop does not (or did they
simply scroll off the bottom on atop display, due to %cpu values?)
- we could make a pmdaproc filter for this, if we need it? (lemme
know, I'm hacking in that PMDA at the moment).
I've confirmed all of the above are not simple sampling differences,
FWIW - values are consistently different, where reported above.
That's the static stuff. As discussed on IRC the other day, when we
start resizing the window, pmatop short-comings relative to atop are
quickly evident as well (atop does a fabulous job of resize handling
as discussed, seamless adjustments - feeding the new size back into
each and every column right away - neat stuff).
There's also all the interactive options (disk, net, etc) to change
the displayed metrics, but we already knew those had not been tackled
at this stage (I think?).
Stepping back, we can probably learn a few things about our strategy
for building new PCP tools via mimicry - it may be a better plan (esp
now that the python APIs are maturing) to start with the existing C
code and convert it to python (license permitting, of course), rather
than starting with a blank canvas and building the tool from scratch.
Maybe? Or - maybe we could use a guideline of "start afresh with new
clean Python code, but use the C/Perl code of the existing code as a
very direct reference"? Mainly for folks starting new tools I mean -
like iostat (Hi Mark!). The atop/pmatop feature disparity was a fair
bit larger than I realised, anyway, maybe its just a complex tool and
will take us time to reach that sort of level.
That said, I worry a bit that if we tell people "use the PCP version
of atop" or similar not-quite-ready tools, it may leave a poor first
impression of PCP in general. So lets keep going with these tools,
moving 'em forward. The good news is the tools we're mimicking are
only infrequently changing - so for us to reach feature parity should
be eventually achievable, in general.
cheers.
--
Nathan
atop-vs-pmatop.png
Description: PNG image
|
