Thanks for the letter.
> 0. You probably want to consider changing the basic operational model
> for how you present the metrics in the Values setup dialog ... in
> addition to the issues of instance "numbers" vs instance "names" and
> memory footprint you've identified, you should consider ...
>
The note about memory usage is because currently the instance ID is
taken as
an index to an array, so if the name resolves to ID 1000, 1000*sizeof(double)
bytes is
allocated. I can either create another hash table (but that would be
overcomplicated in 99% of the cases), or create simple array and linearly scan
it which will be OK as long as the user doesn't use too many instances (up to
10-20) of one PM.
> a) the namespace can be much larger, e.g. on my local Irix server
> $ pminfo | wc -l
> 1552
> b) the number of instances can be even larger, e.g. on the same
> local Irix server
> $ pminfo -F | grep ' value ' | wc -l
> 27911
> c) the namespace can be different on different hosts
> d) the instances are expected to be different on different hosts
> e) metrics with the same name on different hosts do not necessarily
> have the same metric id, e.g. bruce is a Linux system, snort is
> an Irix system ...
> f) instances with the same name on different hosts do not necessarily
> have the same instance number
That should be all OK in the current version, since PMIDs and instance
IDs are
resolved when program starts/metric is added. See also note about the predefined
values below.
> g) the namespace and instances change over time even on the same host
>
As long as the IDs remain constant this should pose no problem.
Otherwise
simple bringing up the values dialog and clicking OK causes all symbolic names
to be resolved again.
> a) only the top-level metrics are displayed by default, e.g. on
> my local Linux system this would be:
>
> + disk
> + filesys
> + hinv
> + kernel
> + mem
> + mpi
>
It seems you didn't get the "predefined values" dialog - the values are
not
from PNMS, they are predefined expressions for beginner users.
> 1. I don't think your scaling model is going to work ... as soon as
> you have 2 metrics in the same chart you have 2 choices:
> a) auto-scale to a single y axis, or
> b) independently scale each plot and (optionally) annotate the
> left and right axes with the two scales.
>
> We chose a). You've opted for b). I think b) is less desirable
> because
> - the visual message is wrong (two values with a similar y
> value in the chart _should_ have the same _real_ value for
> the underlying metrics), and
> - this model does not scale beyond 2 plots in the same chart
>
Partially right. There's no problem to choose a), you just check "show on left
axis" for both values. So it clearly scales beyond 2 plots, you can have as many
graphs as you can. The graphs get too dense with about five graphs anyway, so
some algorithms in the PCP count with the fact that the number of values is
generaly small (up to 10-20).
When you decide to show values on different axes in one graph, they are usualy
not same but have some correlation - like number of HTTP requests vs network
traffic. And what you want to see is the corelation.
> 2. PCP metrics have metadata to describe the dimension and scale of the
> values. We've found it important to use this to prevent "silly"
> combinations of metrics in the same chart, and to annotate the graph
> axes.
>
> 3. I like the expression evaluator ... this is a special case of something
> called a "derived metric" that we've been fighting with for a long
> time ... the semantics of derived metrics is very tricky if you
> want to restrict the user to only "sensible" combinations ... if
> that is not a concern, then go for it.
>
These two must be considered together - descriptions and semantics are
nice,
but if you compute value from an expression, it is tricky, as you write. There
is note by the delta operator that it cannot use the "counter" semantics to
handle overflows, so the overflows are handled by heuristics "if the last
value was bigger than 3G and current is lower than 1G, it is overflowed
counter".
> 4. I had to upgrade from 1.0.0 to 1.8.7 for libxml and libxml-devel
> before pcpmon would link ... the unresolved symbol was
> xmlSubstituteEntitiesDefault ... you may want to check the
> dependencies, either in the configure script or your web page.
>
OK, I will check if this symbol is present in the configure.
> 5. And finally, a couple of trivial patches to remove some compilation
> warnings:
>
Thanks, they have been applied to my working version.
> Keep up the good work.
>
Thanks for the comments.
Michal Kara
P.S.: I am already on the PCP list, so you can answer there.
|