nathans wrote:
> [...] Thoughts? [...] #1 is nearly complete, #2 builds on that, #3
> and #4 build further on that groundwork. Are there any scenarios /
> cases we know of that will not be covered by #1 - #4 above?
A few thoughts.
One constant in this scheme is the use of MMV as the transport of data
to PCP. One aspect that doesn't go away (even if the various known
MMV bugs were to be fixed) is the one-way, unsynchronized data-flow of
that system.
This means that it relies on regular polling of a mass of jvm data by
the java agent (whether within-jvm or extenral-to-jvm), for updating
the MMV shared memory bits, whether or not a PCP client exists, or is
actively monitoring any of it. Marko had already run into cases where
this step alone could take on the order of seconds of CPU time (for
many metrics).
Assuming a constant background overhead such as this is tolerable, it
becomes critical to configure it properly, so an a-priori predicted
set of metrics and a polling rate must be specified. What type of
tooling is going to assist in this?
How do you plan to address the scenario where a fixed-configuration,
constant background-polling overhead is not tolerable, where a dynamic
pull-based scheme is a better fit?
- FChE
|