Re: Parfait agent, docs, rpm updates

Hi -

nscott wrote:

> [...]
> > Just for the sake of clarity, does there exist any sample configuration
> > in the parfait sources that allows preexisting JMX metrics from the
> > core-JVM or an app running within the JVM to be relayed to PCP via
> > parfait-agent?
> 
> Yes - this is the default mode, have a look at the Spring configuration
> files in Parfait.  Those are built into parfait-agent (i.e. in the jar)
> [...]

OK, I found one, mbeans.xml identifying some 40-odd metrics - a subset
of what jconsole can find on a barenaked jvm.  Has anything larger
been tested with this code?  It would be easier to find & extend if
the file were installed as a visible file in /etc/parfait rather than
bundled in the .jar.


> [...]
> > does there exist any tooling to generate those files?
> 
> This has been discussed several times already - Marko and I even recently
> discussed it right here on the list, again.  [...]

AIUI that means "no", ok.  That suggests that creating a new test for
scaling is not easy.


> [...]
> > Does there exist a design that eventually will not rely on
> > JVM-side regular internal polling of JMX,

> Parfait doesn't rely on JMX, so this statement doesn't really make sense.

I am referring to the pcp parfait-agent's JMX polling.  It's only this
agent that makes this whole java/parfait discussion relevant to PCP.


> FWLIW, there is no evidence that the memory copying that you're
> asserting is expensive, actually is.  [...]

It's not plain "memory copying".  It's invoking potentially hundreds
or thousands synchronized Java methods on application objects,
regularly.


> > regardless of the presence or absence of PCP/MMV consumers of the data?
> 
> This could certainly be done in the existing Parfait, yes, if there was a
> need (but there is not AFAIK).  The application could be poked independently
> of the PCP infrastructure to tune any refresh interval, and/or set of values
> exported.  [...]

My point with asking this is that this sort of dynamic behaviour would
more ideally be *part of* the PCP infrastructure, and not require
poking outside it.  Use of the MMV mechanism precludes this because it
provides no information to the self-instrumenting program about what
if anything PCP clients are actually consuming, so it goes polling and
polling and polling, potentially for nothing.  Measuring the actual
pcp-parfait-agent-induced overheads for Java apps of some realistic
size would be great, but not sure that has been or can be done.

But this is unappealing, even just on principle.  I'm sure it can be
made manageable by not being too ambitious with the mbeans*.xml and
tweaking the pmda/agent-side polling interval as large as acceptable
for each particular machine & situation.  But it just doesn't seem
like the "PCP Way", where individual downstream PCP data consumers run
the show (examining any subset of a smorgasbord of metrics, at any
desired rate), ad-hoc experiments welcome.


- FChE

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#14970): https://groups.io/g/pcp/message/14970
View All Messages In Topic (14): https://groups.io/g/pcp/topic/2984744
Mute This Topic: https://groups.io/mt/2984744?uid=174580
New Topic: https://groups.io/g/pcp/post
-=-=-
pcp mailing list
[email protected]
https://groups.io/g/pcp/messages
-=-=-
Change Your Subscription: https://groups.io/g/pcp/editsub?uid=174580
Group Home: https://groups.io/g/pcp
Contact Group Owner: [email protected]
Terms of Service: https://groups.io/static/tos
Unsubscribe: https://groups.io/g/pcp/leave/354243/563757577/xyzzy
-=-=-=-=-=-=-=-=-=-=-=-