On Mon, 10 Apr 2000, Michal Kara wrote:
> Hello!
>
> I have downloaded your Performance Co-Pilot software. Due to my work
> for Czech portal (centrum.cz), I am very interested in performance
> monitoring. However I greatly missed a graphic monitor to show me
> graphical performance statistics.
There are all manner of 2-D and 3-D performance visualization tools
built over the PCP protocols. Unfortunately, most of these are
currently kept private by SGI, and bundled with various solution
bundles. In most cases these applications use libraries and
technologies that cannot be open sourced, even if we wanted to release
the SGI developed code.
> So I have written one under the GTK library. Check it out, I have
> attached the source archive to this letter. It requires GTK and libxml
> (to read/write configuration).
This is great. The more people who use the PCP protocols to develop
value-added tools to consume performance data:
1. the more useful PCP becomes, and
2. the more pressure there is on SGI to innovate at the high end and
release more of the lower-level tools over time.
Can you please help me identify the RPMs I need to install so that I can
build this? At the moment, configure dies thusly ...
...
checking for gtk-config... /usr/bin/gtk-config
checking for GTK - version >= 1.2.0... yes
checking for gzopen in -lgz... no
configure: error: libgz not found (required for libxml)
Your mail to the list at oss.sgi.com bounced due to a size limit ... if
I can make this work I'll put it up on a "contrib" area below
http://www.oss.sgi.com/projects/pcp, and mail to the list.
> I also have one question: How stable are indexes assigned to symbolic
> value instance names? Currently it is only possible to index by number
> in the monitor, but it will be necessary to index by name too. And I
> don't want to check the index on every fetch.
Good question.
This is in a murky area we've been describing generically for some
time as "dynamic instance domains". In practice they occur rather
infrequently (the proc.* metrics is the most obvious example), and
we've adopted a position that is as follows:
1. an agent exporting metrics should be free to add and delete
instances on the fly.
2. an agent should try very hard to _not_ re-assign the same _internal_
instance identifier (the integer) to different instances and in
particular to different _external_ instance identifiers (the string)
as follows:
(a) never in the life of the one exection of the agent, and
(b) not if it can be avoided between one execution of the agent and
the next.
3. given 1. and 2., most clients will operate according to the
principle of "least suprise" if they enumerate the instance domain
at start up and then ignore any changes ... instances that go away
will return "no values" which is OK, new instances that appear will
be ignored, which is often OK.
4. when the dynamic nature of an instance domain is important, the
client can request "all instances" and then only has to do something
different when consecutive fetches return a different set of
instances ... this is _exactly_ what pmie does, for example.
|