Memory usage per cache

[dmagda]

Igniters,

Glad to see that 2.4 made it possible to show memory usage in bytes for
data regions. Good progress but it's definitely not enough.

I'd like to discuss how we can support "memory usage per cache/table" in
bytes. That's actually what the users are interested in. Talking to Alex G.
we came up with 2 possible approaches:

1. Usage of a per cache counter that accumulates total size of all binary
objects passed through our cache update/insert/remove API. Pros: easy to
implement. Cons: we don't consider extra space taken by our data pages and
other memory components.

2. To address the cons of 1. we can count the size of the data pages, but
in that scenario, a data page must not store entries of varies cache. This
approach is ideal for the memory usage by cache reporting but requires more
changes in the architecture side.

Alex G., please step in and give more details suggesting your approach.

Others, please join the discussion as well.

--
Denis

[Andrey Kuznetsov]

Denis,

Do we really need to measure cache sizes precisely? We can use approach 1
and also we have average pagesFillFactor metric. These two metrics can give
a good estimation of page memory size per cache.

2018-03-22 21:04 GMT+03:00 Denis Magda <[hidden email]>:

> Igniters,
>
> Glad to see that 2.4 made it possible to show memory usage in bytes for
> data regions. Good progress but it's definitely not enough.
>
> I'd like to discuss how we can support "memory usage per cache/table" in
> bytes. That's actually what the users are interested in. Talking to Alex G.
> we came up with 2 possible approaches:
>
> 1. Usage of a per cache counter that accumulates total size of all binary
> objects passed through our cache update/insert/remove API. Pros: easy to
> implement. Cons: we don't consider extra space taken by our data pages and
> other memory components.
>
> 2. To address the cons of 1. we can count the size of the data pages, but
> in that scenario, a data page must not store entries of varies cache. This
> approach is ideal for the memory usage by cache reporting but requires more
> changes in the architecture side.
>
> Alex G., please step in and give more details suggesting your approach.
>
> Others, please join the discussion as well.
>
> --
> Denis
>

--
Best regards,
  Andrey Kuznetsov.

[dmagda]

Andrey,

How good will be the estimate if we go for 1. and utilize pagesFillFactor
somehow? In other words, how big can be a difference between 100% precise
calculation you the approach you're suggesting?

--
Denis

On Thu, Mar 22, 2018 at 11:17 AM, Andrey Kuznetsov <[hidden email]>
wrote:

> Denis,
>
> Do we really need to measure cache sizes precisely? We can use approach 1
> and also we have average pagesFillFactor metric. These two metrics can give
> a good estimation of page memory size per cache.
>
> 2018-03-22 21:04 GMT+03:00 Denis Magda <[hidden email]>:
>
> > Igniters,
> >
> > Glad to see that 2.4 made it possible to show memory usage in bytes for
> > data regions. Good progress but it's definitely not enough.
> >
> > I'd like to discuss how we can support "memory usage per cache/table" in
> > bytes. That's actually what the users are interested in. Talking to Alex
> G.
> > we came up with 2 possible approaches:
> >
> > 1. Usage of a per cache counter that accumulates total size of all binary
> > objects passed through our cache update/insert/remove API. Pros: easy to
> > implement. Cons: we don't consider extra space taken by our data pages
> and
> > other memory components.
> >
> > 2. To address the cons of 1. we can count the size of the data pages, but
> > in that scenario, a data page must not store entries of varies cache.
> This
> > approach is ideal for the memory usage by cache reporting but requires
> more
> > changes in the architecture side.
> >
> > Alex G., please step in and give more details suggesting your approach.
> >
> > Others, please join the discussion as well.
> >
> > --
> > Denis
> >
>
>
>
> --
> Best regards,
>   Andrey Kuznetsov.
>

[Andrey Kuznetsov]

Denis,

I'll need to conduct some experiments to estimate the difference. And the
answer will depend on numerous parameters: object sizes, number of caches,
that share the same data region and so on.

пт, 23 марта 2018, 21:53 Denis Magda <[hidden email]>:

> Andrey,
>
> How good will be the estimate if we go for 1. and utilize pagesFillFactor
> somehow? In other words, how big can be a difference between 100% precise
> calculation you the approach you're suggesting?
>
> --
> Denis
>
>

[Andrey Kuznetsov]

I apologize for the previous message sent in hurry. It's imposible to
measure the difference between 'precise' and 'estimated' page memory usage
per cache unless we fully implement approach 2. Current model allows to
store objects from several caches in a single page.

2018-03-23 22:21 GMT+03:00 Andrey Kuznetsov <[hidden email]>:

> Denis,
>
> I'll need to conduct some experiments to estimate the difference. And the
> answer will depend on numerous parameters: object sizes, number of caches,
> that share the same data region and so on.
>
> пт, 23 марта 2018, 21:53 Denis Magda <[hidden email]>:
>
>> Andrey,
>>
>> How good will be the estimate if we go for 1. and utilize pagesFillFactor
>> somehow? In other words, how big can be a difference between 100% precise
>> calculation you the approach you're suggesting?
>>
>> --
>> Denis
>>
>>

--
Best regards,
  Andrey Kuznetsov.

[Alexey Goncharuk]

Denis,

Currently there is an easy way to add per-cache-group metrics for data and
index pages. There is an internal counter, but it is not published as an
MBean metric, we will do this as a part of IEP-6.

As for the per-cache metrics, this can be implemented, but it will take a
significantly greater effort and most likely will affect performance. As
Andrey noted, when two caches share the same cache group, multiple entries
may be written to the same page, this needs special handling. I suggest we
first start with per-cache-group metrics and then, if there is high demand,
start thinking about per-cache metrics.

--AG

2018-03-27 15:18 GMT+03:00 Andrey Kuznetsov <[hidden email]>:

> I apologize for the previous message sent in hurry. It's imposible to
> measure the difference between 'precise' and 'estimated' page memory usage
> per cache unless we fully implement approach 2. Current model allows to
> store objects from several caches in a single page.
>
> 2018-03-23 22:21 GMT+03:00 Andrey Kuznetsov <[hidden email]>:
>
> > Denis,
> >
> > I'll need to conduct some experiments to estimate the difference. And the
> > answer will depend on numerous parameters: object sizes, number of
> caches,
> > that share the same data region and so on.
> >
> > пт, 23 марта 2018, 21:53 Denis Magda <[hidden email]>:
> >
> >> Andrey,
> >>
> >> How good will be the estimate if we go for 1. and utilize
> pagesFillFactor
> >> somehow? In other words, how big can be a difference between 100%
> precise
> >> calculation you the approach you're suggesting?
> >>
> >> --
> >> Denis
> >>
> >>
>
>
> --
> Best regards,
>   Andrey Kuznetsov.
>

[dsetrakyan]

On Thu, Mar 29, 2018 at 1:20 AM, Alexey Goncharuk <
[hidden email]> wrote:

> Denis,
>
> Currently there is an easy way to add per-cache-group metrics for data and
> index pages. There is an internal counter, but it is not published as an
> MBean metric, we will do this as a part of IEP-6.
>
> As for the per-cache metrics, this can be implemented, but it will take a
> significantly greater effort and most likely will affect performance. As
> Andrey noted, when two caches share the same cache group, multiple entries
> may be written to the same page, this needs special handling. I suggest we
> first start with per-cache-group metrics and then, if there is high demand,
> start thinking about per-cache metrics.
>

I agree with AG. If user really needs  per-cache metrics, then user can use
one cache per group configuration, which is the default, btw.

D.

[dmagda]

Alexey,

If to rephrase it differently, if a cache/table belongs to a single cache
group then its entries will never be mixed with the entries of another
caches/tables in both data and index pages. Please confirm that my
statement is correct. Also, does that counter accumulates size of
BinaryObjects or the whole data/index pages?

Finally, do you plan to rework CacheMetrics.getOffHeapAllocatedSize method
for this purpose? (btw, to my knowledge the method is broken at the moment
and returns 0).

--
Denis


On Thu, Mar 29, 2018 at 1:20 AM, Alexey Goncharuk <
[hidden email]> wrote:

> Denis,
>
> Currently there is an easy way to add per-cache-group metrics for data and
> index pages. There is an internal counter, but it is not published as an
> MBean metric, we will do this as a part of IEP-6.
>
> As for the per-cache metrics, this can be implemented, but it will take a
> significantly greater effort and most likely will affect performance. As
> Andrey noted, when two caches share the same cache group, multiple entries
> may be written to the same page, this needs special handling. I suggest we
> first start with per-cache-group metrics and then, if there is high demand,
> start thinking about per-cache metrics.
>
> --AG
>
> 2018-03-27 15:18 GMT+03:00 Andrey Kuznetsov <[hidden email]>:
>
> > I apologize for the previous message sent in hurry. It's imposible to
> > measure the difference between 'precise' and 'estimated' page memory
> usage
> > per cache unless we fully implement approach 2. Current model allows to
> > store objects from several caches in a single page.
> >
> > 2018-03-23 22:21 GMT+03:00 Andrey Kuznetsov <[hidden email]>:
> >
> > > Denis,
> > >
> > > I'll need to conduct some experiments to estimate the difference. And
> the
> > > answer will depend on numerous parameters: object sizes, number of
> > caches,
> > > that share the same data region and so on.
> > >
> > > пт, 23 марта 2018, 21:53 Denis Magda <[hidden email]>:
> > >
> > >> Andrey,
> > >>
> > >> How good will be the estimate if we go for 1. and utilize
> > pagesFillFactor
> > >> somehow? In other words, how big can be a difference between 100%
> > precise
> > >> calculation you the approach you're suggesting?
> > >>
> > >> --
> > >> Denis
> > >>
> > >>
> >
> >
> > --
> > Best regards,
> >   Andrey Kuznetsov.
> >
>

[Dmitriy Govorukhin]

Folks,

I created 2 Jira issue for new metrics. Also, I think they will be useful.
Let's discuss in comments.

- Add new metrics for data storage IGNITE-8078
<https://issues.apache.org/jira/browse/IGNITE-8078>
- Implement new JMX metrics for transactions IGNITE-8077
<https://issues.apache.org/jira/browse/IGNITE-8077>

On Thu, Mar 29, 2018 at 8:26 PM, Denis Magda <[hidden email]> wrote:

> Alexey,
>
> If to rephrase it differently, if a cache/table belongs to a single cache
> group then its entries will never be mixed with the entries of another
> caches/tables in both data and index pages. Please confirm that my
> statement is correct. Also, does that counter accumulates size of
> BinaryObjects or the whole data/index pages?
>
> Finally, do you plan to rework CacheMetrics.getOffHeapAllocatedSize method
> for this purpose? (btw, to my knowledge the method is broken at the moment
> and returns 0).
>
> --
> Denis
>
>
> On Thu, Mar 29, 2018 at 1:20 AM, Alexey Goncharuk <
> [hidden email]> wrote:
>
> > Denis,
> >
> > Currently there is an easy way to add per-cache-group metrics for data
> and
> > index pages. There is an internal counter, but it is not published as an
> > MBean metric, we will do this as a part of IEP-6.
> >
> > As for the per-cache metrics, this can be implemented, but it will take a
> > significantly greater effort and most likely will affect performance. As
> > Andrey noted, when two caches share the same cache group, multiple
> entries
> > may be written to the same page, this needs special handling. I suggest
> we
> > first start with per-cache-group metrics and then, if there is high
> demand,
> > start thinking about per-cache metrics.
> >
> > --AG
> >
> > 2018-03-27 15:18 GMT+03:00 Andrey Kuznetsov <[hidden email]>:
> >
> > > I apologize for the previous message sent in hurry. It's imposible to
> > > measure the difference between 'precise' and 'estimated' page memory
> > usage
> > > per cache unless we fully implement approach 2. Current model allows to
> > > store objects from several caches in a single page.
> > >
> > > 2018-03-23 22:21 GMT+03:00 Andrey Kuznetsov <[hidden email]>:
> > >
> > > > Denis,
> > > >
> > > > I'll need to conduct some experiments to estimate the difference. And
> > the
> > > > answer will depend on numerous parameters: object sizes, number of
> > > caches,
> > > > that share the same data region and so on.
> > > >
> > > > пт, 23 марта 2018, 21:53 Denis Magda <[hidden email]>:
> > > >
> > > >> Andrey,
> > > >>
> > > >> How good will be the estimate if we go for 1. and utilize
> > > pagesFillFactor
> > > >> somehow? In other words, how big can be a difference between 100%
> > > precise
> > > >> calculation you the approach you're suggesting?
> > > >>
> > > >> --
> > > >> Denis
> > > >>
> > > >>
> > >
> > >
> > > --
> > > Best regards,
> > >   Andrey Kuznetsov.
> > >
> >
>

[dsetrakyan]

Dmitriy,

For transactions, are these separate metrics for each transaction or
aggregates for all of them? If these are aggregates, then methods like
"getLockedKeys" may produce a very large collection, which on top of
everything else, will be very difficult to create.

D.

On Fri, Mar 30, 2018 at 2:04 AM, Dmitriy Govorukhin <
[hidden email]> wrote:

> Folks,
>
> I created 2 Jira issue for new metrics. Also, I think they will be useful.
> Let's discuss in comments.
>
> - Add new metrics for data storage IGNITE-8078
> <https://issues.apache.org/jira/browse/IGNITE-8078>
> - Implement new JMX metrics for transactions IGNITE-8077
> <https://issues.apache.org/jira/browse/IGNITE-8077>
>
> On Thu, Mar 29, 2018 at 8:26 PM, Denis Magda <[hidden email]> wrote:
>
> > Alexey,
> >
> > If to rephrase it differently, if a cache/table belongs to a single cache
> > group then its entries will never be mixed with the entries of another
> > caches/tables in both data and index pages. Please confirm that my
> > statement is correct. Also, does that counter accumulates size of
> > BinaryObjects or the whole data/index pages?
> >
> > Finally, do you plan to rework CacheMetrics.getOffHeapAllocatedSize
> method
> > for this purpose? (btw, to my knowledge the method is broken at the
> moment
> > and returns 0).
> >
> > --
> > Denis
> >
> >
> > On Thu, Mar 29, 2018 at 1:20 AM, Alexey Goncharuk <
> > [hidden email]> wrote:
> >
> > > Denis,
> > >
> > > Currently there is an easy way to add per-cache-group metrics for data
> > and
> > > index pages. There is an internal counter, but it is not published as
> an
> > > MBean metric, we will do this as a part of IEP-6.
> > >
> > > As for the per-cache metrics, this can be implemented, but it will
> take a
> > > significantly greater effort and most likely will affect performance.
> As
> > > Andrey noted, when two caches share the same cache group, multiple
> > entries
> > > may be written to the same page, this needs special handling. I suggest
> > we
> > > first start with per-cache-group metrics and then, if there is high
> > demand,
> > > start thinking about per-cache metrics.
> > >
> > > --AG
> > >
> > > 2018-03-27 15:18 GMT+03:00 Andrey Kuznetsov <[hidden email]>:
> > >
> > > > I apologize for the previous message sent in hurry. It's imposible to
> > > > measure the difference between 'precise' and 'estimated' page memory
> > > usage
> > > > per cache unless we fully implement approach 2. Current model allows
> to
> > > > store objects from several caches in a single page.
> > > >
> > > > 2018-03-23 22:21 GMT+03:00 Andrey Kuznetsov <[hidden email]>:
> > > >
> > > > > Denis,
> > > > >
> > > > > I'll need to conduct some experiments to estimate the difference.
> And
> > > the
> > > > > answer will depend on numerous parameters: object sizes, number of
> > > > caches,
> > > > > that share the same data region and so on.
> > > > >
> > > > > пт, 23 марта 2018, 21:53 Denis Magda <[hidden email]>:
> > > > >
> > > > >> Andrey,
> > > > >>
> > > > >> How good will be the estimate if we go for 1. and utilize
> > > > pagesFillFactor
> > > > >> somehow? In other words, how big can be a difference between 100%
> > > > precise
> > > > >> calculation you the approach you're suggesting?
> > > > >>
> > > > >> --
> > > > >> Denis
> > > > >>
> > > > >>
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > >   Andrey Kuznetsov.
> > > >
> > >
> >
>

[Alexey Goncharuk]

Dmitriy,

getLockedKeys returns only the number of locked keys, not the keys
themselves. Looks like the method name is confusing, should we rename it to
getLockedKeysNumber?

--AG

2018-03-30 16:24 GMT+03:00 Dmitriy Setrakyan <[hidden email]>:

> Dmitriy,
>
> For transactions, are these separate metrics for each transaction or
> aggregates for all of them? If these are aggregates, then methods like
> "getLockedKeys" may produce a very large collection, which on top of
> everything else, will be very difficult to create.
>
> D.
>
> On Fri, Mar 30, 2018 at 2:04 AM, Dmitriy Govorukhin <
> [hidden email]> wrote:
>
> > Folks,
> >
> > I created 2 Jira issue for new metrics. Also, I think they will be
> useful.
> > Let's discuss in comments.
> >
> > - Add new metrics for data storage IGNITE-8078
> > <https://issues.apache.org/jira/browse/IGNITE-8078>
> > - Implement new JMX metrics for transactions IGNITE-8077
> > <https://issues.apache.org/jira/browse/IGNITE-8077>
> >
> > On Thu, Mar 29, 2018 at 8:26 PM, Denis Magda <[hidden email]> wrote:
> >
> > > Alexey,
> > >
> > > If to rephrase it differently, if a cache/table belongs to a single
> cache
> > > group then its entries will never be mixed with the entries of another
> > > caches/tables in both data and index pages. Please confirm that my
> > > statement is correct. Also, does that counter accumulates size of
> > > BinaryObjects or the whole data/index pages?
> > >
> > > Finally, do you plan to rework CacheMetrics.getOffHeapAllocatedSize
> > method
> > > for this purpose? (btw, to my knowledge the method is broken at the
> > moment
> > > and returns 0).
> > >
> > > --
> > > Denis
> > >
> > >
> > > On Thu, Mar 29, 2018 at 1:20 AM, Alexey Goncharuk <
> > > [hidden email]> wrote:
> > >
> > > > Denis,
> > > >
> > > > Currently there is an easy way to add per-cache-group metrics for
> data
> > > and
> > > > index pages. There is an internal counter, but it is not published as
> > an
> > > > MBean metric, we will do this as a part of IEP-6.
> > > >
> > > > As for the per-cache metrics, this can be implemented, but it will
> > take a
> > > > significantly greater effort and most likely will affect performance.
> > As
> > > > Andrey noted, when two caches share the same cache group, multiple
> > > entries
> > > > may be written to the same page, this needs special handling. I
> suggest
> > > we
> > > > first start with per-cache-group metrics and then, if there is high
> > > demand,
> > > > start thinking about per-cache metrics.
> > > >
> > > > --AG
> > > >
> > > > 2018-03-27 15:18 GMT+03:00 Andrey Kuznetsov <[hidden email]>:
> > > >
> > > > > I apologize for the previous message sent in hurry. It's imposible
> to
> > > > > measure the difference between 'precise' and 'estimated' page
> memory
> > > > usage
> > > > > per cache unless we fully implement approach 2. Current model
> allows
> > to
> > > > > store objects from several caches in a single page.
> > > > >
> > > > > 2018-03-23 22:21 GMT+03:00 Andrey Kuznetsov <[hidden email]>:
> > > > >
> > > > > > Denis,
> > > > > >
> > > > > > I'll need to conduct some experiments to estimate the difference.
> > And
> > > > the
> > > > > > answer will depend on numerous parameters: object sizes, number
> of
> > > > > caches,
> > > > > > that share the same data region and so on.
> > > > > >
> > > > > > пт, 23 марта 2018, 21:53 Denis Magda <[hidden email]>:
> > > > > >
> > > > > >> Andrey,
> > > > > >>
> > > > > >> How good will be the estimate if we go for 1. and utilize
> > > > > pagesFillFactor
> > > > > >> somehow? In other words, how big can be a difference between
> 100%
> > > > > precise
> > > > > >> calculation you the approach you're suggesting?
> > > > > >>
> > > > > >> --
> > > > > >> Denis
> > > > > >>
> > > > > >>
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > >   Andrey Kuznetsov.
> > > > >
> > > >
> > >
> >
>

[dsetrakyan]

I think "getLockedKeysCount" is better. Can we easily return this count
without traversing all the transactions?



On Fri, Mar 30, 2018 at 7:32 AM, Alexey Goncharuk <
[hidden email]> wrote:

> Dmitriy,
>
> getLockedKeys returns only the number of locked keys, not the keys
> themselves. Looks like the method name is confusing, should we rename it to
> getLockedKeysNumber?
>
> --AG
>
> 2018-03-30 16:24 GMT+03:00 Dmitriy Setrakyan <[hidden email]>:
>
> > Dmitriy,
> >
> > For transactions, are these separate metrics for each transaction or
> > aggregates for all of them? If these are aggregates, then methods like
> > "getLockedKeys" may produce a very large collection, which on top of
> > everything else, will be very difficult to create.
> >
> > D.
> >
> > On Fri, Mar 30, 2018 at 2:04 AM, Dmitriy Govorukhin <
> > [hidden email]> wrote:
> >
> > > Folks,
> > >
> > > I created 2 Jira issue for new metrics. Also, I think they will be
> > useful.
> > > Let's discuss in comments.
> > >
> > > - Add new metrics for data storage IGNITE-8078
> > > <https://issues.apache.org/jira/browse/IGNITE-8078>
> > > - Implement new JMX metrics for transactions IGNITE-8077
> > > <https://issues.apache.org/jira/browse/IGNITE-8077>
> > >
> > > On Thu, Mar 29, 2018 at 8:26 PM, Denis Magda <[hidden email]>
> wrote:
> > >
> > > > Alexey,
> > > >
> > > > If to rephrase it differently, if a cache/table belongs to a single
> > cache
> > > > group then its entries will never be mixed with the entries of
> another
> > > > caches/tables in both data and index pages. Please confirm that my
> > > > statement is correct. Also, does that counter accumulates size of
> > > > BinaryObjects or the whole data/index pages?
> > > >
> > > > Finally, do you plan to rework CacheMetrics.getOffHeapAllocatedSize
> > > method
> > > > for this purpose? (btw, to my knowledge the method is broken at the
> > > moment
> > > > and returns 0).
> > > >
> > > > --
> > > > Denis
> > > >
> > > >
> > > > On Thu, Mar 29, 2018 at 1:20 AM, Alexey Goncharuk <
> > > > [hidden email]> wrote:
> > > >
> > > > > Denis,
> > > > >
> > > > > Currently there is an easy way to add per-cache-group metrics for
> > data
> > > > and
> > > > > index pages. There is an internal counter, but it is not published
> as
> > > an
> > > > > MBean metric, we will do this as a part of IEP-6.
> > > > >
> > > > > As for the per-cache metrics, this can be implemented, but it will
> > > take a
> > > > > significantly greater effort and most likely will affect
> performance.
> > > As
> > > > > Andrey noted, when two caches share the same cache group, multiple
> > > > entries
> > > > > may be written to the same page, this needs special handling. I
> > suggest
> > > > we
> > > > > first start with per-cache-group metrics and then, if there is high
> > > > demand,
> > > > > start thinking about per-cache metrics.
> > > > >
> > > > > --AG
> > > > >
> > > > > 2018-03-27 15:18 GMT+03:00 Andrey Kuznetsov <[hidden email]>:
> > > > >
> > > > > > I apologize for the previous message sent in hurry. It's
> imposible
> > to
> > > > > > measure the difference between 'precise' and 'estimated' page
> > memory
> > > > > usage
> > > > > > per cache unless we fully implement approach 2. Current model
> > allows
> > > to
> > > > > > store objects from several caches in a single page.
> > > > > >
> > > > > > 2018-03-23 22:21 GMT+03:00 Andrey Kuznetsov <[hidden email]>:
> > > > > >
> > > > > > > Denis,
> > > > > > >
> > > > > > > I'll need to conduct some experiments to estimate the
> difference.
> > > And
> > > > > the
> > > > > > > answer will depend on numerous parameters: object sizes, number
> > of
> > > > > > caches,
> > > > > > > that share the same data region and so on.
> > > > > > >
> > > > > > > пт, 23 марта 2018, 21:53 Denis Magda <[hidden email]>:
> > > > > > >
> > > > > > >> Andrey,
> > > > > > >>
> > > > > > >> How good will be the estimate if we go for 1. and utilize
> > > > > > pagesFillFactor
> > > > > > >> somehow? In other words, how big can be a difference between
> > 100%
> > > > > > precise
> > > > > > >> calculation you the approach you're suggesting?
> > > > > > >>
> > > > > > >> --
> > > > > > >> Denis
> > > > > > >>
> > > > > > >>
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > >   Andrey Kuznetsov.
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Alexey Goncharuk]

Yes, I think we can maintain this metric inside lock ownership change
callbacks.

2018-03-30 17:34 GMT+03:00 Dmitriy Setrakyan <[hidden email]>:

> I think "getLockedKeysCount" is better. Can we easily return this count
> without traversing all the transactions?
>
>
>
> On Fri, Mar 30, 2018 at 7:32 AM, Alexey Goncharuk <
> [hidden email]> wrote:
>
> > Dmitriy,
> >
> > getLockedKeys returns only the number of locked keys, not the keys
> > themselves. Looks like the method name is confusing, should we rename it
> to
> > getLockedKeysNumber?
> >
> > --AG
> >
> > 2018-03-30 16:24 GMT+03:00 Dmitriy Setrakyan <[hidden email]>:
> >
> > > Dmitriy,
> > >
> > > For transactions, are these separate metrics for each transaction or
> > > aggregates for all of them? If these are aggregates, then methods like
> > > "getLockedKeys" may produce a very large collection, which on top of
> > > everything else, will be very difficult to create.
> > >
> > > D.
> > >
> > > On Fri, Mar 30, 2018 at 2:04 AM, Dmitriy Govorukhin <
> > > [hidden email]> wrote:
> > >
> > > > Folks,
> > > >
> > > > I created 2 Jira issue for new metrics. Also, I think they will be
> > > useful.
> > > > Let's discuss in comments.
> > > >
> > > > - Add new metrics for data storage IGNITE-8078
> > > > <https://issues.apache.org/jira/browse/IGNITE-8078>
> > > > - Implement new JMX metrics for transactions IGNITE-8077
> > > > <https://issues.apache.org/jira/browse/IGNITE-8077>
> > > >
> > > > On Thu, Mar 29, 2018 at 8:26 PM, Denis Magda <[hidden email]>
> > wrote:
> > > >
> > > > > Alexey,
> > > > >
> > > > > If to rephrase it differently, if a cache/table belongs to a single
> > > cache
> > > > > group then its entries will never be mixed with the entries of
> > another
> > > > > caches/tables in both data and index pages. Please confirm that my
> > > > > statement is correct. Also, does that counter accumulates size of
> > > > > BinaryObjects or the whole data/index pages?
> > > > >
> > > > > Finally, do you plan to rework CacheMetrics.
> getOffHeapAllocatedSize
> > > > method
> > > > > for this purpose? (btw, to my knowledge the method is broken at the
> > > > moment
> > > > > and returns 0).
> > > > >
> > > > > --
> > > > > Denis
> > > > >
> > > > >
> > > > > On Thu, Mar 29, 2018 at 1:20 AM, Alexey Goncharuk <
> > > > > [hidden email]> wrote:
> > > > >
> > > > > > Denis,
> > > > > >
> > > > > > Currently there is an easy way to add per-cache-group metrics for
> > > data
> > > > > and
> > > > > > index pages. There is an internal counter, but it is not
> published
> > as
> > > > an
> > > > > > MBean metric, we will do this as a part of IEP-6.
> > > > > >
> > > > > > As for the per-cache metrics, this can be implemented, but it
> will
> > > > take a
> > > > > > significantly greater effort and most likely will affect
> > performance.
> > > > As
> > > > > > Andrey noted, when two caches share the same cache group,
> multiple
> > > > > entries
> > > > > > may be written to the same page, this needs special handling. I
> > > suggest
> > > > > we
> > > > > > first start with per-cache-group metrics and then, if there is
> high
> > > > > demand,
> > > > > > start thinking about per-cache metrics.
> > > > > >
> > > > > > --AG
> > > > > >
> > > > > > 2018-03-27 15:18 GMT+03:00 Andrey Kuznetsov <[hidden email]>:
> > > > > >
> > > > > > > I apologize for the previous message sent in hurry. It's
> > imposible
> > > to
> > > > > > > measure the difference between 'precise' and 'estimated' page
> > > memory
> > > > > > usage
> > > > > > > per cache unless we fully implement approach 2. Current model
> > > allows
> > > > to
> > > > > > > store objects from several caches in a single page.
> > > > > > >
> > > > > > > 2018-03-23 22:21 GMT+03:00 Andrey Kuznetsov <[hidden email]
> >:
> > > > > > >
> > > > > > > > Denis,
> > > > > > > >
> > > > > > > > I'll need to conduct some experiments to estimate the
> > difference.
> > > > And
> > > > > > the
> > > > > > > > answer will depend on numerous parameters: object sizes,
> number
> > > of
> > > > > > > caches,
> > > > > > > > that share the same data region and so on.
> > > > > > > >
> > > > > > > > пт, 23 марта 2018, 21:53 Denis Magda <[hidden email]>:
> > > > > > > >
> > > > > > > >> Andrey,
> > > > > > > >>
> > > > > > > >> How good will be the estimate if we go for 1. and utilize
> > > > > > > pagesFillFactor
> > > > > > > >> somehow? In other words, how big can be a difference between
> > > 100%
> > > > > > > precise
> > > > > > > >> calculation you the approach you're suggesting?
> > > > > > > >>
> > > > > > > >> --
> > > > > > > >> Denis
> > > > > > > >>
> > > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best regards,
> > > > > > >   Andrey Kuznetsov.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[dmagda]

Dmitriy G., Alexey,

What happens with CacheMetrics.getOffHeapAllocatedSize metric? Don't see it
mentioned in the tickets.

   - Will it return a value of a respective cache group if the cache is the
   only one in the group.
   - What will it return if there are several caches in a group?

--
Denis

On Fri, Mar 30, 2018 at 8:16 AM, Alexey Goncharuk <
[hidden email]> wrote:

> Yes, I think we can maintain this metric inside lock ownership change
> callbacks.
>
> 2018-03-30 17:34 GMT+03:00 Dmitriy Setrakyan <[hidden email]>:
>
> > I think "getLockedKeysCount" is better. Can we easily return this count
> > without traversing all the transactions?
> >
> >
> >
> > On Fri, Mar 30, 2018 at 7:32 AM, Alexey Goncharuk <
> > [hidden email]> wrote:
> >
> > > Dmitriy,
> > >
> > > getLockedKeys returns only the number of locked keys, not the keys
> > > themselves. Looks like the method name is confusing, should we rename
> it
> > to
> > > getLockedKeysNumber?
> > >
> > > --AG
> > >
> > > 2018-03-30 16:24 GMT+03:00 Dmitriy Setrakyan <[hidden email]>:
> > >
> > > > Dmitriy,
> > > >
> > > > For transactions, are these separate metrics for each transaction or
> > > > aggregates for all of them? If these are aggregates, then methods
> like
> > > > "getLockedKeys" may produce a very large collection, which on top of
> > > > everything else, will be very difficult to create.
> > > >
> > > > D.
> > > >
> > > > On Fri, Mar 30, 2018 at 2:04 AM, Dmitriy Govorukhin <
> > > > [hidden email]> wrote:
> > > >
> > > > > Folks,
> > > > >
> > > > > I created 2 Jira issue for new metrics. Also, I think they will be
> > > > useful.
> > > > > Let's discuss in comments.
> > > > >
> > > > > - Add new metrics for data storage IGNITE-8078
> > > > > <https://issues.apache.org/jira/browse/IGNITE-8078>
> > > > > - Implement new JMX metrics for transactions IGNITE-8077
> > > > > <https://issues.apache.org/jira/browse/IGNITE-8077>
> > > > >
> > > > > On Thu, Mar 29, 2018 at 8:26 PM, Denis Magda <[hidden email]>
> > > wrote:
> > > > >
> > > > > > Alexey,
> > > > > >
> > > > > > If to rephrase it differently, if a cache/table belongs to a
> single
> > > > cache
> > > > > > group then its entries will never be mixed with the entries of
> > > another
> > > > > > caches/tables in both data and index pages. Please confirm that
> my
> > > > > > statement is correct. Also, does that counter accumulates size of
> > > > > > BinaryObjects or the whole data/index pages?
> > > > > >
> > > > > > Finally, do you plan to rework CacheMetrics.
> > getOffHeapAllocatedSize
> > > > > method
> > > > > > for this purpose? (btw, to my knowledge the method is broken at
> the
> > > > > moment
> > > > > > and returns 0).
> > > > > >
> > > > > > --
> > > > > > Denis
> > > > > >
> > > > > >
> > > > > > On Thu, Mar 29, 2018 at 1:20 AM, Alexey Goncharuk <
> > > > > > [hidden email]> wrote:
> > > > > >
> > > > > > > Denis,
> > > > > > >
> > > > > > > Currently there is an easy way to add per-cache-group metrics
> for
> > > > data
> > > > > > and
> > > > > > > index pages. There is an internal counter, but it is not
> > published
> > > as
> > > > > an
> > > > > > > MBean metric, we will do this as a part of IEP-6.
> > > > > > >
> > > > > > > As for the per-cache metrics, this can be implemented, but it
> > will
> > > > > take a
> > > > > > > significantly greater effort and most likely will affect
> > > performance.
> > > > > As
> > > > > > > Andrey noted, when two caches share the same cache group,
> > multiple
> > > > > > entries
> > > > > > > may be written to the same page, this needs special handling. I
> > > > suggest
> > > > > > we
> > > > > > > first start with per-cache-group metrics and then, if there is
> > high
> > > > > > demand,
> > > > > > > start thinking about per-cache metrics.
> > > > > > >
> > > > > > > --AG
> > > > > > >
> > > > > > > 2018-03-27 15:18 GMT+03:00 Andrey Kuznetsov <[hidden email]
> >:
> > > > > > >
> > > > > > > > I apologize for the previous message sent in hurry. It's
> > > imposible
> > > > to
> > > > > > > > measure the difference between 'precise' and 'estimated' page
> > > > memory
> > > > > > > usage
> > > > > > > > per cache unless we fully implement approach 2. Current model
> > > > allows
> > > > > to
> > > > > > > > store objects from several caches in a single page.
> > > > > > > >
> > > > > > > > 2018-03-23 22:21 GMT+03:00 Andrey Kuznetsov <
> [hidden email]
> > >:
> > > > > > > >
> > > > > > > > > Denis,
> > > > > > > > >
> > > > > > > > > I'll need to conduct some experiments to estimate the
> > > difference.
> > > > > And
> > > > > > > the
> > > > > > > > > answer will depend on numerous parameters: object sizes,
> > number
> > > > of
> > > > > > > > caches,
> > > > > > > > > that share the same data region and so on.
> > > > > > > > >
> > > > > > > > > пт, 23 марта 2018, 21:53 Denis Magda <[hidden email]>:
> > > > > > > > >
> > > > > > > > >> Andrey,
> > > > > > > > >>
> > > > > > > > >> How good will be the estimate if we go for 1. and utilize
> > > > > > > > pagesFillFactor
> > > > > > > > >> somehow? In other words, how big can be a difference
> between
> > > > 100%
> > > > > > > > precise
> > > > > > > > >> calculation you the approach you're suggesting?
> > > > > > > > >>
> > > > > > > > >> --
> > > > > > > > >> Denis
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best regards,
> > > > > > > >   Andrey Kuznetsov.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[dmagda]

Dmitriy G., Alex G.,

Reminder. Still hope to get an answer to the question below.

--
Denis

On Fri, Mar 30, 2018 at 10:04 AM, Denis Magda <[hidden email]> wrote:

> Dmitriy G., Alexey,
>
> What happens with CacheMetrics.getOffHeapAllocatedSize metric? Don't see
> it mentioned in the tickets.
>
>    - Will it return a value of a respective cache group if the cache is
>    the only one in the group.
>    - What will it return if there are several caches in a group?
>
> --
> Denis
>
> On Fri, Mar 30, 2018 at 8:16 AM, Alexey Goncharuk <
> [hidden email]> wrote:
>
>> Yes, I think we can maintain this metric inside lock ownership change
>> callbacks.
>>
>> 2018-03-30 17:34 GMT+03:00 Dmitriy Setrakyan <[hidden email]>:
>>
>> > I think "getLockedKeysCount" is better. Can we easily return this count
>> > without traversing all the transactions?
>> >
>> >
>> >
>> > On Fri, Mar 30, 2018 at 7:32 AM, Alexey Goncharuk <
>> > [hidden email]> wrote:
>> >
>> > > Dmitriy,
>> > >
>> > > getLockedKeys returns only the number of locked keys, not the keys
>> > > themselves. Looks like the method name is confusing, should we rename
>> it
>> > to
>> > > getLockedKeysNumber?
>> > >
>> > > --AG
>> > >
>> > > 2018-03-30 16:24 GMT+03:00 Dmitriy Setrakyan <[hidden email]>:
>> > >
>> > > > Dmitriy,
>> > > >
>> > > > For transactions, are these separate metrics for each transaction or
>> > > > aggregates for all of them? If these are aggregates, then methods
>> like
>> > > > "getLockedKeys" may produce a very large collection, which on top of
>> > > > everything else, will be very difficult to create.
>> > > >
>> > > > D.
>> > > >
>> > > > On Fri, Mar 30, 2018 at 2:04 AM, Dmitriy Govorukhin <
>> > > > [hidden email]> wrote:
>> > > >
>> > > > > Folks,
>> > > > >
>> > > > > I created 2 Jira issue for new metrics. Also, I think they will be
>> > > > useful.
>> > > > > Let's discuss in comments.
>> > > > >
>> > > > > - Add new metrics for data storage IGNITE-8078
>> > > > > <https://issues.apache.org/jira/browse/IGNITE-8078>
>> > > > > - Implement new JMX metrics for transactions IGNITE-8077
>> > > > > <https://issues.apache.org/jira/browse/IGNITE-8077>
>> > > > >
>> > > > > On Thu, Mar 29, 2018 at 8:26 PM, Denis Magda <[hidden email]>
>> > > wrote:
>> > > > >
>> > > > > > Alexey,
>> > > > > >
>> > > > > > If to rephrase it differently, if a cache/table belongs to a
>> single
>> > > > cache
>> > > > > > group then its entries will never be mixed with the entries of
>> > > another
>> > > > > > caches/tables in both data and index pages. Please confirm that
>> my
>> > > > > > statement is correct. Also, does that counter accumulates size
>> of
>> > > > > > BinaryObjects or the whole data/index pages?
>> > > > > >
>> > > > > > Finally, do you plan to rework CacheMetrics.
>> > getOffHeapAllocatedSize
>> > > > > method
>> > > > > > for this purpose? (btw, to my knowledge the method is broken at
>> the
>> > > > > moment
>> > > > > > and returns 0).
>> > > > > >
>> > > > > > --
>> > > > > > Denis
>> > > > > >
>> > > > > >
>> > > > > > On Thu, Mar 29, 2018 at 1:20 AM, Alexey Goncharuk <
>> > > > > > [hidden email]> wrote:
>> > > > > >
>> > > > > > > Denis,
>> > > > > > >
>> > > > > > > Currently there is an easy way to add per-cache-group metrics
>> for
>> > > > data
>> > > > > > and
>> > > > > > > index pages. There is an internal counter, but it is not
>> > published
>> > > as
>> > > > > an
>> > > > > > > MBean metric, we will do this as a part of IEP-6.
>> > > > > > >
>> > > > > > > As for the per-cache metrics, this can be implemented, but it
>> > will
>> > > > > take a
>> > > > > > > significantly greater effort and most likely will affect
>> > > performance.
>> > > > > As
>> > > > > > > Andrey noted, when two caches share the same cache group,
>> > multiple
>> > > > > > entries
>> > > > > > > may be written to the same page, this needs special handling.
>> I
>> > > > suggest
>> > > > > > we
>> > > > > > > first start with per-cache-group metrics and then, if there is
>> > high
>> > > > > > demand,
>> > > > > > > start thinking about per-cache metrics.
>> > > > > > >
>> > > > > > > --AG
>> > > > > > >
>> > > > > > > 2018-03-27 15:18 GMT+03:00 Andrey Kuznetsov <
>> [hidden email]>:
>> > > > > > >
>> > > > > > > > I apologize for the previous message sent in hurry. It's
>> > > imposible
>> > > > to
>> > > > > > > > measure the difference between 'precise' and 'estimated'
>> page
>> > > > memory
>> > > > > > > usage
>> > > > > > > > per cache unless we fully implement approach 2. Current
>> model
>> > > > allows
>> > > > > to
>> > > > > > > > store objects from several caches in a single page.
>> > > > > > > >
>> > > > > > > > 2018-03-23 22:21 GMT+03:00 Andrey Kuznetsov <
>> [hidden email]
>> > >:
>> > > > > > > >
>> > > > > > > > > Denis,
>> > > > > > > > >
>> > > > > > > > > I'll need to conduct some experiments to estimate the
>> > > difference.
>> > > > > And
>> > > > > > > the
>> > > > > > > > > answer will depend on numerous parameters: object sizes,
>> > number
>> > > > of
>> > > > > > > > caches,
>> > > > > > > > > that share the same data region and so on.
>> > > > > > > > >
>> > > > > > > > > пт, 23 марта 2018, 21:53 Denis Magda <[hidden email]>:
>> > > > > > > > >
>> > > > > > > > >> Andrey,
>> > > > > > > > >>
>> > > > > > > > >> How good will be the estimate if we go for 1. and utilize
>> > > > > > > > pagesFillFactor
>> > > > > > > > >> somehow? In other words, how big can be a difference
>> between
>> > > > 100%
>> > > > > > > > precise
>> > > > > > > > >> calculation you the approach you're suggesting?
>> > > > > > > > >>
>> > > > > > > > >> --
>> > > > > > > > >> Denis
>> > > > > > > > >>
>> > > > > > > > >>
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > --
>> > > > > > > > Best regards,
>> > > > > > > >   Andrey Kuznetsov.
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

[Alexey Goncharuk]

Denis,

I think this particular metric should be deprecated. The most we can do
about it is to return the actual allocated size when a cache is the only
cache in a group and return -1 if there are multiple caches in a group.
However, this does not look like a consistent approach to me, so I would
prefer to always return -1 and suggest that users use corresponding cache
group metrics.

--AG

2018-03-30 20:04 GMT+03:00 Denis Magda <[hidden email]>:

> Dmitriy G., Alexey,
>
> What happens with CacheMetrics.getOffHeapAllocatedSize metric? Don't see
> it
> mentioned in the tickets.
>
>    - Will it return a value of a respective cache group if the cache is the
>    only one in the group.
>    - What will it return if there are several caches in a group?
>
> --
> Denis
>
> On Fri, Mar 30, 2018 at 8:16 AM, Alexey Goncharuk <
> [hidden email]> wrote:
>
> > Yes, I think we can maintain this metric inside lock ownership change
> > callbacks.
> >
> > 2018-03-30 17:34 GMT+03:00 Dmitriy Setrakyan <[hidden email]>:
> >
> > > I think "getLockedKeysCount" is better. Can we easily return this count
> > > without traversing all the transactions?
> > >
> > >
> > >
> > > On Fri, Mar 30, 2018 at 7:32 AM, Alexey Goncharuk <
> > > [hidden email]> wrote:
> > >
> > > > Dmitriy,
> > > >
> > > > getLockedKeys returns only the number of locked keys, not the keys
> > > > themselves. Looks like the method name is confusing, should we rename
> > it
> > > to
> > > > getLockedKeysNumber?
> > > >
> > > > --AG
> > > >
> > > > 2018-03-30 16:24 GMT+03:00 Dmitriy Setrakyan <[hidden email]
> >:
> > > >
> > > > > Dmitriy,
> > > > >
> > > > > For transactions, are these separate metrics for each transaction
> or
> > > > > aggregates for all of them? If these are aggregates, then methods
> > like
> > > > > "getLockedKeys" may produce a very large collection, which on top
> of
> > > > > everything else, will be very difficult to create.
> > > > >
> > > > > D.
> > > > >
> > > > > On Fri, Mar 30, 2018 at 2:04 AM, Dmitriy Govorukhin <
> > > > > [hidden email]> wrote:
> > > > >
> > > > > > Folks,
> > > > > >
> > > > > > I created 2 Jira issue for new metrics. Also, I think they will
> be
> > > > > useful.
> > > > > > Let's discuss in comments.
> > > > > >
> > > > > > - Add new metrics for data storage IGNITE-8078
> > > > > > <https://issues.apache.org/jira/browse/IGNITE-8078>
> > > > > > - Implement new JMX metrics for transactions IGNITE-8077
> > > > > > <https://issues.apache.org/jira/browse/IGNITE-8077>
> > > > > >
> > > > > > On Thu, Mar 29, 2018 at 8:26 PM, Denis Magda <[hidden email]>
> > > > wrote:
> > > > > >
> > > > > > > Alexey,
> > > > > > >
> > > > > > > If to rephrase it differently, if a cache/table belongs to a
> > single
> > > > > cache
> > > > > > > group then its entries will never be mixed with the entries of
> > > > another
> > > > > > > caches/tables in both data and index pages. Please confirm that
> > my
> > > > > > > statement is correct. Also, does that counter accumulates size
> of
> > > > > > > BinaryObjects or the whole data/index pages?
> > > > > > >
> > > > > > > Finally, do you plan to rework CacheMetrics.
> > > getOffHeapAllocatedSize
> > > > > > method
> > > > > > > for this purpose? (btw, to my knowledge the method is broken at
> > the
> > > > > > moment
> > > > > > > and returns 0).
> > > > > > >
> > > > > > > --
> > > > > > > Denis
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Mar 29, 2018 at 1:20 AM, Alexey Goncharuk <
> > > > > > > [hidden email]> wrote:
> > > > > > >
> > > > > > > > Denis,
> > > > > > > >
> > > > > > > > Currently there is an easy way to add per-cache-group metrics
> > for
> > > > > data
> > > > > > > and
> > > > > > > > index pages. There is an internal counter, but it is not
> > > published
> > > > as
> > > > > > an
> > > > > > > > MBean metric, we will do this as a part of IEP-6.
> > > > > > > >
> > > > > > > > As for the per-cache metrics, this can be implemented, but it
> > > will
> > > > > > take a
> > > > > > > > significantly greater effort and most likely will affect
> > > > performance.
> > > > > > As
> > > > > > > > Andrey noted, when two caches share the same cache group,
> > > multiple
> > > > > > > entries
> > > > > > > > may be written to the same page, this needs special
> handling. I
> > > > > suggest
> > > > > > > we
> > > > > > > > first start with per-cache-group metrics and then, if there
> is
> > > high
> > > > > > > demand,
> > > > > > > > start thinking about per-cache metrics.
> > > > > > > >
> > > > > > > > --AG
> > > > > > > >
> > > > > > > > 2018-03-27 15:18 GMT+03:00 Andrey Kuznetsov <
> [hidden email]
> > >:
> > > > > > > >
> > > > > > > > > I apologize for the previous message sent in hurry. It's
> > > > imposible
> > > > > to
> > > > > > > > > measure the difference between 'precise' and 'estimated'
> page
> > > > > memory
> > > > > > > > usage
> > > > > > > > > per cache unless we fully implement approach 2. Current
> model
> > > > > allows
> > > > > > to
> > > > > > > > > store objects from several caches in a single page.
> > > > > > > > >
> > > > > > > > > 2018-03-23 22:21 GMT+03:00 Andrey Kuznetsov <
> > [hidden email]
> > > >:
> > > > > > > > >
> > > > > > > > > > Denis,
> > > > > > > > > >
> > > > > > > > > > I'll need to conduct some experiments to estimate the
> > > > difference.
> > > > > > And
> > > > > > > > the
> > > > > > > > > > answer will depend on numerous parameters: object sizes,
> > > number
> > > > > of
> > > > > > > > > caches,
> > > > > > > > > > that share the same data region and so on.
> > > > > > > > > >
> > > > > > > > > > пт, 23 марта 2018, 21:53 Denis Magda <[hidden email]
> >:
> > > > > > > > > >
> > > > > > > > > >> Andrey,
> > > > > > > > > >>
> > > > > > > > > >> How good will be the estimate if we go for 1. and
> utilize
> > > > > > > > > pagesFillFactor
> > > > > > > > > >> somehow? In other words, how big can be a difference
> > between
> > > > > 100%
> > > > > > > > > precise
> > > > > > > > > >> calculation you the approach you're suggesting?
> > > > > > > > > >>
> > > > > > > > > >> --
> > > > > > > > > >> Denis
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Best regards,
> > > > > > > > >   Andrey Kuznetsov.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[dsetrakyan]

On Wed, Apr 4, 2018 at 5:27 AM, Alexey Goncharuk <[hidden email]
> wrote:

> Denis,
>
> I think this particular metric should be deprecated. The most we can do
> about it is to return the actual allocated size when a cache is the only
> cache in a group and return -1 if there are multiple caches in a group.
> However, this does not look like a consistent approach to me, so I would
> prefer to always return -1 and suggest that users use corresponding cache
> group metrics.
>

Why not return cache group metrics from this method by default and properly
document it?

[dmagda]

Alex,

Why not return cache group metrics from this method by default and properly
> document it?


What do you think about Dmitry's suggestion? It sounds reasonable to me.

--
Denis

On Wed, Apr 4, 2018 at 12:22 PM, Dmitriy Setrakyan <[hidden email]>
wrote:

> On Wed, Apr 4, 2018 at 5:27 AM, Alexey Goncharuk <
> [hidden email]
> > wrote:
>
> > Denis,
> >
> > I think this particular metric should be deprecated. The most we can do
> > about it is to return the actual allocated size when a cache is the only
> > cache in a group and return -1 if there are multiple caches in a group.
> > However, this does not look like a consistent approach to me, so I would
> > prefer to always return -1 and suggest that users use corresponding cache
> > group metrics.
> >
>
> Why not return cache group metrics from this method by default and properly
> document it?
>

[Alexey Goncharuk]

Sounds good to me.

Folks, any other feedback on metrics API in IGNITE-8078?

2018-04-06 21:36 GMT+03:00 Denis Magda <[hidden email]>:

> Alex,
>
> Why not return cache group metrics from this method by default and properly
> > document it?
>
>
> What do you think about Dmitry's suggestion? It sounds reasonable to me.
>
> --
> Denis
>
> On Wed, Apr 4, 2018 at 12:22 PM, Dmitriy Setrakyan <[hidden email]>
> wrote:
>
> > On Wed, Apr 4, 2018 at 5:27 AM, Alexey Goncharuk <
> > [hidden email]
> > > wrote:
> >
> > > Denis,
> > >
> > > I think this particular metric should be deprecated. The most we can do
> > > about it is to return the actual allocated size when a cache is the
> only
> > > cache in a group and return -1 if there are multiple caches in a group.
> > > However, this does not look like a consistent approach to me, so I
> would
> > > prefer to always return -1 and suggest that users use corresponding
> cache
> > > group metrics.
> > >
> >
> > Why not return cache group metrics from this method by default and
> properly
> > document it?
> >
>

[dmagda]

Alex, Dmitriy,

Please clarify/consider the following:

   - Can we get the size of a particular secondary index with a method like
   getIndexSize(indexName)? Vladimir Ozerov
   <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=vozerov>,
   it should be feasible, right?
   - The new DataRegionMXBean metrics list is not the same as of
   DataRegionMetricsMXBean interface. Why is so that and what's the
   difference between such similar interfaces?
   - I wouldn't do this - *Depricate
   CacheMetrics.getRebalancingPartitionsCount(); and move to
   CacheGroupMetricsMXBean.getRebalancingPartitionsCount()*. If we redesign
   the way we store our data within data pages in the future, then
   CacheMetrics.getRebalancingPartitionsCount() would make sense.


--
Denis

On Thu, Apr 12, 2018 at 8:46 AM, Alexey Goncharuk <
[hidden email]> wrote:

> Sounds good to me.
>
> Folks, any other feedback on metrics API in IGNITE-8078?
>
> 2018-04-06 21:36 GMT+03:00 Denis Magda <[hidden email]>:
>
> > Alex,
> >
> > Why not return cache group metrics from this method by default and
> properly
> > > document it?
> >
> >
> > What do you think about Dmitry's suggestion? It sounds reasonable to me.
> >
> > --
> > Denis
> >
> > On Wed, Apr 4, 2018 at 12:22 PM, Dmitriy Setrakyan <
> [hidden email]>
> > wrote:
> >
> > > On Wed, Apr 4, 2018 at 5:27 AM, Alexey Goncharuk <
> > > [hidden email]
> > > > wrote:
> > >
> > > > Denis,
> > > >
> > > > I think this particular metric should be deprecated. The most we can
> do
> > > > about it is to return the actual allocated size when a cache is the
> > only
> > > > cache in a group and return -1 if there are multiple caches in a
> group.
> > > > However, this does not look like a consistent approach to me, so I
> > would
> > > > prefer to always return -1 and suggest that users use corresponding
> > cache
> > > > group metrics.
> > > >
> > >
> > > Why not return cache group metrics from this method by default and
> > properly
> > > document it?
> > >
> >
>