BigMemory Configuration, Cache Sizing and Pinning
The JVM settings are found in
apache-tomcat/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.
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: