[
https://issues.apache.org/jira/browse/GEODE-8859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17269462#comment-17269462
]
Darrel Schneider commented on GEODE-8859:
-----------------------------------------
Setting the system property "gemfire.DELTAS_RECALCULATE_SIZE" to "true" would
fix this issue. The only problem with doing this is it is a global setting for
the whole JVM it is set in. It would be better if geode offered us something
that would only change the behavior of how redis deltas are sized. One option
would be to add a new default method on the Delta interface which by default
returns false but that implementors of Delta could override and have it return
true. This new method could be named "isSizeCalculatedOnUpdate". The redis
Delta classes would implement the method to return true. The only places that
need to call this new method are the same places in geode that currently check
the system property (two places).
> Redis data structures may not accurately reflect their size in Geode stats
> --------------------------------------------------------------------------
>
> Key: GEODE-8859
> URL: https://issues.apache.org/jira/browse/GEODE-8859
> Project: Geode
> Issue Type: Improvement
> Components: statistics
> Reporter: Jens Deppe
> Priority: Major
>
> Here is a comment from Darrel regarding this issue. For some background, the
> Redis structures implement {{Delta}}.
>
> {quote}I was playing around with RedisInsight and was able to get most the
> the overview dashboard and the data browser working with geode redis. But I
> found a problem with how we are using geode that causes the geode stats that
> track how much data is stored in a partitioned region to be wrong and the
> bucket sizes used for rebalancing are also wrong. Basically when we do create
> ops on the region the stats track it okay. But when we do updates then geode
> always thinks that nothing (size wise) changed. So for example I created a
> string by doing a redis “set” command. I saw the size of the string accounted
> for in dataStoreBytesInUse. But then I kept doing redis “append” commands on
> that key and the dataStoreBytesInUse did not change at all. I think the
> problem is in how we are updating the data structure in place instead of
> getting a copy, modifying it, and then putting the copy into the region.
> Avoiding this copy gives us MUCH better performance but it messes up geode
> when it is trying to calculate the memory increase or decrease. It is
> possible that this is only an issue on the primary and that the secondary
> sizing may be correct. If so that could lead to other problems because for a
> given bucket our primary size would be different than the secondary. The
> bucket sizes are used when you do a rebalance but basically we can have a
> bunch of memory that is “untracked” so we might see the JVM heaps unbalanced
> but geode will think the buckets are balanced. I’m not sure what we should do
> about this.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
