Opinions sought on information presentation

Wed Apr 20 12:28:46 PDT 2011

On Wed, Apr 20, 2011 at 11:57:40AM -0700, Steve Acheson wrote:
> HI David,
> 
> Nice work.  I like the graph and I think it's pretty obvious to anyone
> that does this kind of work what it represents.  But, I think that if
> this is for non-technical audiences you might want to choose a different
> style of graph.

Thanks.

This is strictly for technical folks.  :-}

> I'm actually interested in your solution, and I have a question for you
> around it.  Did you look into gathering the information via SNMP and
> found that it wasn't adequate resolution for your needs or was there
> some other reason for going the on-box perl/shell route?

I wanted the basic "information gathering" to be able to work on a stock
FreeBSD system, without requiring any changes to its current
configuration -- even if it had no ports installed at all.  (In FreeBSD
terminology, a "port" is a 3rd-party application, not part of FreeBSD,
and thus, not in /usr/src.  Examples include Perl, X11, and Web-related
programs.)

While I bent things a bit to use a Perl script to "shepherd" the
workload under test, in our environment, any system capable of running
that workload would have Perl installed.  It is not (necessarily) the
case that any such system would have an SNMP agent configured in any
particular way.

So you could say that I was trying to reduce external dependencies.

I also have used something very similar for ongoing system resource
usage measurement, and in that role, the output is directed back through
an SSH tunnel -- which I trust a fair amount more than SNMP if any of
the data traverses a network component over which I do not have control.

Further, using this approach, I can capture just about any sysctl(8)
output for which the result is restricted to a single line.  (I haven't
figured out a reasonable way to parse the output of, say, "sysctl
vm.vmtotal":

d130(8.2-S)[7] sysctl vm.vmtotal
vm.vmtotal: 
System wide totals computed every five seconds: (values in kilobytes)
===============================================
Processes:              (RUNQ: 1 Disk Wait: 0 Page Wait: 0 Sleep: 129)
Virtual Memory:         (Total: 3858892K Active: 1678116K)
Real Memory:            (Total: 958340K Active: 438576K)
Shared Virtual Memory:  (Total: 85196K Active: 53540K)
Shared Real Memory:     (Total: 48420K Active: 24296K)
Free Memory Pages:      2500324K

d130(8.2-S)[8] 

within the constraints I've imposed.  (The original version only coped
with univariate OIDs; I needed to be more flexible to get the CPU
utilization.  Extracting the per-core CPU utilization was a little
trickier, but not too bad.)

About the constraints: when the shell script starts up, it constructs a
string.  It then sits in a loop, alternately feeding the string to
"eval", then determining how long to sleep, then sleeping.  Lather,
rinse, repeat....

The programs the shell script uses are:

* awk
* date
* kill
* netstat
* ps
* sleep
* sysctl
* unlink

Of those, ps and unlink are only (potentially) used in the initial phase.

Also, the shell script make no attempt to interpret anything: it merely
gathers information, re-formats it to a uniform syntax, and reports it.
(Well, and sleeps a lot.  Reminds me of certain resident felines.)

I have found some ... oddities -- such as OIDs that I thought ought to
be treated as COUNTERs (RRDtool terminology), but yet, they are actually
treated as signed -- so when they wrap around, <0 values can be
reported.  I rather suspect that's a bug; on the other hand, it's
plausible that fixing it would break some things.... :-{

> Overall looks good tho, I can see where it would be useful for gathering
> performance metrics for a workload run.

Seeing what happens to the individual cores (over time) can be ...
fascinating.

Thanks again.

Peace,
david
-- 
David H. Wolfskill				david at catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://www.baylisa.org/pipermail/baylisa/attachments/20110420/1df4bbf6/attachment.bin>