ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrey Gura (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (IGNITE-11927) [IEP-35] Add ability to enable\disable subset of metrics
Date Thu, 18 Jul 2019 14:08:00 GMT

    [ https://issues.apache.org/jira/browse/IGNITE-11927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16887990#comment-16887990
] 

Andrey Gura edited comment on IGNITE-11927 at 7/18/19 2:07 PM:
---------------------------------------------------------------

[~NIzhikov]

> Can you, please, make a simple, pseudo-code example of your idea?

Caches, for example. Not pseudo-code, but list of action items.

On cache start or metrics enabling on cache:

- create metrics holder object.
- create MetricRegistry instance.
- register metrics in MetricRegistry.
- add MetricsRegistry in GridMetricManager.

On cache stop or metrics disabling for chache:

- remove MetricRegistry from GridMetricManager.
- assign null to metrics holder object reference.

> 1. If we have 5000 caches, Ignite structures already huge. Why do you think metrics bring
a huge impact on GC?

Why we should ignore this impact if we can just avoid it without much effort?

> 2. All AtomicLong fields are created in previous versions of CacheMetricsImpl. MetricRegistry
is the only addition we made with the new framework.

You are right. But this addition lead to some changes in design. It's good time to improve
implementation.

Also, I think it would be better design if MetricRegistry will be immutable. It will lead
to more clear code structure and behavior.

> Do we have some benchmarks or other descriptions of this issue?

No, we don't. But obviously all this objects in heap are not free.



was (Author: agura):
[~NIzhikov]

> Can you, please, make a simple, pseudo-code example of your idea?

Caches, for example. Not pseudo-code, but list of action items.

On cache start or metrics enabling on cache:

- create metrics holder object.
- create MetricRegistry instance.
- register metrics in MetricRegistry.
- add MetricsRegistry in GridMetricManager.

On cache stop or metrics disabling for chache:

- remove MetricRegistry from GridMetricManager.
- assign null to metrics holder object reference.

> 1. If we have 5000 caches, Ignite structures already huge. Why do you think metrics bring
a huge impact on GC?

Why we should ignore this impact if we can just avoid it without much effort?

> 2. All AtomicLong fields are created in previous versions of CacheMetricsImpl. MetricRegistry
is the only addition we made with the new framework.

You are right. But this addition lead to some changes in design. It's good time to improve
implementation.

> Do we have some benchmarks or other descriptions of this issue?

No, we don't. But obviously all this objects in heap are not free.

> [IEP-35] Add ability to enable\disable subset of metrics
> --------------------------------------------------------
>
>                 Key: IGNITE-11927
>                 URL: https://issues.apache.org/jira/browse/IGNITE-11927
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Nikolay Izhikov
>            Assignee: Nikolay Izhikov
>            Priority: Major
>              Labels: IEP-35
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Ignite should be able to:
> * Enable or disable an arbitrary subset of the metrics. User should be able to do it
in runtime.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Mime
View raw message