BigMemory Configuration, Cache Sizing and Pinning

MashZone NextGen Analytics : Working with MashZone NextGen Analytics In-Memory Stores : About BigMemory and the MashZone NextGen Analytics In-Memory Stores : Memory Management and Configuration : BigMemory Configuration, Cache Sizing and Pinning

MashZone NextGen Default JVM Settings

The MashZone NextGen default JVM settings are -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512M -Xmx1G, 1 GByte Heap, no direct memory configuration supplied. The committed memory is 661MB.

The JVM settings are found in apache-tomee-jaxrs/bin/setenv.bat script.

Note:

There are no Garbage Collector settings specified. However the default Garbage Collector settings should work fine with Heap Size up to several GByte.

Default BigMemory Settings

The default settings for dynamic caches are <ehcache name="dynamiccache" overflowToOffHeap="true" maxBytesLocalHeap="500M">.

Additionally each cache is configured with pinning=”incache”.

Meaning:

overflowToOffHeap on CacheManager level has no effect.

BigMemory is actually never used with this default configCaches act as normal Java Objects. When the heap is full, you get an OoME.

Eviction policy is LRU (default). However no eviction should take place with this config, instead when there is no more space available, you'll get an OoME.

Note:

If a CacheManager has a pool configured for using off-heap, the overflowToOffHeap attribute is automatically set to true.

To use off-heap capabilities you have to install a Terracotta license. See Manage Licenses for MashZone NextGen, Universal Messaging and BigMemory.

Notes on eviction

BigMemory is a cache and not a store. This means eviction is a central part of BigMemory . You can configure how eviction is done but you can never have a complete control over eviction. However with the appropriate configuration, BigMemory can be used as in-memory store.

Eviction takes place when there is not enough space in the cache and new data is coming. A cache has a certain size and thus number of max elements that can live in the cache. Older, less accessed elements get evicted if the number of elements in the cache exceeds the maximum.

Default eviction strategy is Least Recently Used.

Setting ethernal=”true” in a cache configuration does NOT prevent eviction.

Pinning has two options:

1. inCache – Data is stored in any storage tier of the cache, depending on performance. Unexpired entries can never be evicted. If configured size is exceeded, you get an OoME. Without an offheap configuration, everything lands in the heap and the limit it when the JVM is out of memory.

2. localMemory – Entries are evicted only when the store's configured size is exceeded. In a TSA scenario, entries are faulted from the server.

Pinning is always local (L1 level), it is never distributed in a cluster

Means to overcome Eviction:

Size caches so data fits into them! Leave 30% Room to avoid Throttling.

Locally you can overflow to disk(slow) or use TSA for better performance.

Pinning could be an option to override cache sizes but this is not best practice and you get OoME instead of eviction. At least makes the ‘damage’ visible.

See links for details:

http://terracotta.org/documentation/4.1/bigmemorymax/configuration/data-life

Configure BigMemory Servers for MashZone NextGen Caching and In-Memory Stores

Contact Support | Community | Feedback