Configure Data Eviction

This topic explains how to configure data eviction in VMware Tanzu GemFire.

Configure a region’s eviction-attributes settings to keep your region within a specified limit.

Configure data eviction as follows. You do not need to perform these steps in the sequence shown.

1. Decide whether to evict based on:

   • Entry count (useful if your entry sizes are relatively uniform).
   • Total bytes used.
     • In partitioned regions, set this using local-max-memory and eviction-max-memory, where the value that you set is the same for each. If you set different values for these, the value for local-max-memory will override and replace the eviction-max-memory value.
     • In non-partitioned regions, set this using only the eviction-max-memory parameter.
   • Percentage of application heap used. This uses the Tanzu GemFire resource manager. When the manager determines that eviction is required, the manager orders the eviction controller to start evicting from all regions where the eviction algorithm is set to lru-heap-percentage. Eviction continues until the manager calls a halt. Tanzu GemFire evicts the least recently used entry hosted by the member for the region. See Managing Heap and Off-heap Memory.

2. Decide what action to take when the limit is reached:

   • Locally destroy the entry.
   • Overflow the entry data to disk. See Persistence and Overflow.

3. Decide the maximum amount of data to allow in the member for the eviction measurement indicated. This is the maximum for all storage for the region in the member. For partitioned regions, this is the total for all buckets stored in the member for the region, including any secondary buckets used for redundancy. This only applies to entry count and memory LRU eviction algorithms. If heap LRU is used, then the maximum amount of data is defined on server startup as a percentage of total heap, and considers all heap memory usage from all sources, not just an individual region.

4. Decide whether to program a custom sizer for your region. If you are able to provide such a class, it might be faster than the standard sizing done by Tanzu GemFire. Your custom class must follow the guidelines for defining custom classes and, additionally, must implement org.apache.geode.cache.util.ObjectSizer. See Requirements for Using Custom Classes in Data Caching.

Examples:

Set an LRU memory eviction threshold of 1000 MB. Use a custom class for measuring the size of each object in the region:

gfsh>create region --name=myRegion --type=REPLICATE --eviction-max-memory=1000 \
--eviction-action=overflow-to-disk --eviction-object-sizer=com.myLib.MySizer

Create an eviction threshold on a partitioned region with a maximum entry count of 512:

gfsh>create region --name=myRegion --type=PARTITION --eviction-entry-count=512 \
--eviction-action=overflow-to-disk 

To configure a partitioned region for heap LRU eviction, first configure the resource manager on server startup, then create a region with eviction enabled:

gfsh>start server --name=Server1 --eviction-heap-percentage=80
...
gfsh>create region --name=myRegion --type=PARTITION --eviction-action=overflow-to-disk