Archived
This forum has been archived. Please start a new discussion on GitHub.
IceMX question on GroupBy
Hi,
I started playing with metrics and can't make sense of the following behavior:
Grid configuration Configuration:
This gives me two tables: Operation dispatch and Invocations. Invocations count up like expected, but operation dispatch metrics reset every few seconds (current is always 0 and total resets).
If I use
the per adapter statistics for Operation Dispatch count up as expected.
Is this intentional, so that the data can be mapped over time for graphing it? And if so, what are the exact rules - I couldn't find anything stating this explicitly in the documentation.
Cheers,
Michael
p.s. - Are there any known bugs in metrics at this point (I experienced some strange behavior like disabled counters getting enables) and are there any known problems/limitations when using metrics with encapsulation version 1.0?
I started playing with metrics and can't make sense of the following behavior:
Grid configuration Configuration:
<property name="IceMX.Metrics.GroupByOperation.GroupBy" value="operation"/> <property name="IceMX.Metrics.GroupByOperation.Disabled" value="0"/>
This gives me two tables: Operation dispatch and Invocations. Invocations count up like expected, but operation dispatch metrics reset every few seconds (current is always 0 and total resets).
If I use
<property name="IceMX.Metrics.GroupByParent.GroupBy" value="parent"/>
the per adapter statistics for Operation Dispatch count up as expected.
Is this intentional, so that the data can be mapped over time for graphing it? And if so, what are the exact rules - I couldn't find anything stating this explicitly in the documentation.
Cheers,
Michael
p.s. - Are there any known bugs in metrics at this point (I experienced some strange behavior like disabled counters getting enables) and are there any known problems/limitations when using metrics with encapsulation version 1.0?
0
Comments
-
Hi Michael,
The operation dispatch should count up as does the invocation, i have been trying to reproduce the behavior you mention using the IceGrid simple demo and IceGrid Admin to watch the metrics, but was unable.(I experienced some strange behavior like disabled counters getting enables)
We don't have any open bugs that could explain this.
No, to map data overtime we use the timestamp out parameter of getMetricsViewIs this intentional, so that the data can be mapped over time for graphing it?
Will be helpful if you can reproduce the issue using any of Ice demos, so we can investigate it further.
Cheers,
Jose0 -
Facepalm
Hi xdm,
After trying to reproduce the issue in a stripped down example for hours I looked at the Ice sources and realized that RetainDetached is set to ten by default. Since we're running many IceBoxes with shared communicators in production and therefore have more than ten possible operations in one metrics admin, they basically got "evicted" after a while.
IceMX Metrics Properties - Ice 3.5 - ZeroC says:prefix.RetainDetached
Synopsis
prefix.RetainedDetached=num
Description
If num is set to a value larger than zero, up to num metrics object whose current value is 0 will be kept in memory by the metrics map. This is useful to prevent indefinite memory growth if the monitoring of an instrumented object or operation creates a unique metrics object, only the last num metrics object will be kept in memory.
Even though this doesn't explicitly specify it, it leaves the reader with the impression that it's probably zero by default. I'd suggest to update the documentation to explicitly state the default value of ten.
Cheers,
Michael
p.s. I probably would've noticed this a lot earlier if IceGridGUI showed more than five entries at a time. I posted this patch earlier today, that - among other things - allows to configure the height of metrics tables.0 -
Hi Michael,
Thanks, I've fixed the documentation to specify the default value of 10.
Cheers,
Benoit.0
