You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2017/06/05 18:50:04 UTC

[jira] [Commented] (GEODE-1672) When amount of overflowed persisted data exceeds heap size startup may run out of memory

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

ASF GitHub Bot commented on GEODE-1672:
---------------------------------------

GitHub user davebarnes97 opened a pull request:

    https://github.com/apache/geode/pull/559

    GEODE-1672 When amount of overflowed persisted data exceeds heap size…

    … startup may run out of memory
    
    This PR Documents a newly-added system property, recoverLRUValues, that allows the developer to fine-tune restart behavior on persistent regions with an LRU eviction policy that saves overflow values to disk. It also picks up a few typo and formatting corrections in related text.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/davebarnes97/geode feature/GEODE-1672

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/geode/pull/559.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #559
    
----
commit 3df55de9fda367ed507f2c2e1dedcdeb76705163
Author: Dave Barnes <db...@pivotal.io>
Date:   2017-06-05T18:25:44Z

    GEODE-1672 When amount of overflowed persisted data exceeds heap size startup may run out of memory

----


> When amount of overflowed persisted data exceeds heap size startup may run out of memory
> ----------------------------------------------------------------------------------------
>
>                 Key: GEODE-1672
>                 URL: https://issues.apache.org/jira/browse/GEODE-1672
>             Project: Geode
>          Issue Type: Bug
>          Components: docs, persistence
>            Reporter: Darrel Schneider
>            Assignee: Anilkumar Gingade
>             Fix For: 1.2.0
>
>
> Basically, when the amount of data overflowed approaches the heap size, ,such that the total amount of data is very close to or actually surpasses your total tenured heap, it is possible that you will not be able to restart.
> The algorithm during recovery of oplogs/buckets is such that we don't "evict" in the normal sense as data fills the heap during early stages of recovery prior to creating the regions. When the data is first created in the heap, it's not yet official in the region.
> At any rate, if during this early phase of recovery, or during subsequent phase where eviction is working as usual, it is possible that the total data or an early imbalance of buckets prior to the opportunity to rebalance causes us to surpass the critical threshold which will kill us before successful startup.
> To reproduce, you could have 1 region with tons of data that evicts and overflows with persistence. Call it R1. Then another region with persistence that does not evict. Call it R2.
> List R1 fist in the cache.xml file. Start running the system and add data over time until you have overflowed tons of data approaching the heap size in the evicted region, and also have enough data in the R2 region.
> Once you fill these regions with enough data and have overflowed enough to disk and persisted the other region, then shutdown, and then attempt to restart. If you put enough data in, you will hit the critical threshold before being able to complete startup.
> You can work around this issue by configuring geode to not recovery values by setting this system property: -Dgemfire.disk.recoverValues=false
> Values will not be faulted into memory until a read operation is done on that value's key.
> If you have regions that do not use overflow and some that do then another work around is the create the regions that do not use overflow first. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)