Memory usage per cache

[Vladimir Ozerov]

Igniters,

I have several questions regarding overall metrics design:
1) Why we split PK and non-PK indexes? This is merely implementation detail
and It is not clear why we want to pin it on public API forever. Other
database vendors allow users to get size of specific index. For now I would
only show total size of all indexes, and add something like
"indexSize(String indexName)" method later
2) What is the purpose of "reuseList" metric? Same as p.1 - this is
internal stuff, why do we think users need it? I think it makes sense to
split "public" and "private" parts, "Public" - this is what makes sense
from user perspective and will not change in future. "Private" - is our
internal details which we can show, but do not guarantee that they will not
change over time.
3) What is the difference between "data size" and "data pages size"?

On Fri, Apr 13, 2018 at 1:41 AM, Denis Magda <[hidden email]> wrote:

> 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?
> > > >
> > >
> >
>

[Denis Magda]

Vladimir,

For now I would
> only show total size of all indexes, and add something like
> "indexSize(String indexName)" method later


Is there any technical or architectural limitation that prevents us from
adding this method right now? I thought that if we could show the size of a
PK, then we know how to get this information for secondary indexes as well.

--
Denis

On Fri, Apr 13, 2018 at 2:52 AM, Vladimir Ozerov <[hidden email]>
wrote:

> Igniters,
>
> I have several questions regarding overall metrics design:
> 1) Why we split PK and non-PK indexes? This is merely implementation detail
> and It is not clear why we want to pin it on public API forever. Other
> database vendors allow users to get size of specific index. For now I would
> only show total size of all indexes, and add something like
> "indexSize(String indexName)" method later
> 2) What is the purpose of "reuseList" metric? Same as p.1 - this is
> internal stuff, why do we think users need it? I think it makes sense to
> split "public" and "private" parts, "Public" - this is what makes sense
> from user perspective and will not change in future. "Private" - is our
> internal details which we can show, but do not guarantee that they will not
> change over time.
> 3) What is the difference between "data size" and "data pages size"?
>
> On Fri, Apr 13, 2018 at 1:41 AM, Denis Magda <[hidden email]> wrote:
>
> > 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?
> > > > >
> > > >
> > >
> >
>