LATEST VERSION: 8.1.0 - CHANGELOG
Pivotal GemFire® v8.1

Resource Manager Example Configurations

Resource Manager Example Configurations

These examples set the critical threshold to 85 percent of the tenured heap and the eviction threshold to 75 percent.

The region bigDataStore is configured to participate in the resource manager's eviction activities.
  • gfsh Example:
    gfsh>start server --name=server1 --initial-heap=30MB --max-heap=30MB \
    --critical-heap-percentage=85 --eviction-heap-percentage=75
    gfsh>create region --name=bigDataStore --type=PARTITION_HEAP_LRU
  • XML:
    <cache>
       <region name="bigDataStore" refid="PARTITION_HEAP_LRU"/>
        ...	
       <resource-manager critical-heap-percentage="85" eviction-heap-percentage="75"/>
    </cache>
    Note: The resource-manager specification must appear after the region declarations in your cache.xml file.
  • Java:
    Cache cache = CacheFactory.create();
    
    ResourceManager rm = cache.getResourceManager();
    rm.setCriticalHeapPercentage(85);
    rm.setEvictionHeapPercentage(75);
    
    RegionFactory rf = 
    	cache.createRegionFactory(RegionShortcut.PARTITION_HEAP_LRU);
    Region region = rf.create("bigDataStore");

Use Case for the Example Code

This is one possible scenario for the configuration used in the examples:
  • A 64-bit Sun Java VM 1.6 JVM, with 8 Gb of heap space on an 4 CPU system running Linux.
  • The data region bigDataStore has approximately 2-3 million small values with average entry size of 512 bytes. So approximately 4-6 Gb of the heap is for region storage.
  • The member hosting the region also runs an application that may take up to 1 Gb of the heap.
  • The application must never run out of heap space and has been crafted such that data loss in the region is acceptable if the heap space becomes limited due to application issues, so the default lru-heap-percentage action destroy is suitable.
  • The application's service guarantee makes it very intolerant of OutOfMemoryExceptions. Testing has shown that leaving 15% head room above the critical threshold when adding data to the region gives 99.5% uptime with no OutOfMemoryExceptions, when configured with the CMS garbage collector using -XX:CMSInitiatingOccupancyFraction=70.