BigMemory 4.3.10 | Product Documentation | BigMemory Max Configuration Guide | Sizing Storage Tiers | Pooling Resources Versus Sizing Individual Data Sets
 
Pooling Resources Versus Sizing Individual Data Sets
You can constrain the size of any data set on a specific tier in that data set's configuration. You can also constrain the size of all of a CacheManager's data sets in a specific tier by configuring an overall size at the CacheManager level.
If there is no CacheManager-level pool specified for a tier, an individual data set claims the amount of that tier specified in its configuration. If there is a CacheManager-level pool specified for a tier, an individual data set claims that amount from the pool. In this case, data sets with no size configuration for that tier receive an equal share of the remainder of the pool (after data sets with explicit sizing configuration have claimed their portion).
For example, if a CacheManager with eight data sets pools one gigabyte of heap, and two data sets each explicitly specify 200MB of heap while the remaining data sets do not specify a size, the remaining data sets will share 600MB of heap equally. Note that data sets must use bytes-based attributes to claim a portion of a pool; entries-based attributes such as maxEntriesLocal cannot be used with a pool.
On startup, the sizes specified by data sets are checked to ensure that any CacheManager-level pools are not over-allocated. If over-allocation occurs for any pool, an InvalidConfigurationException is thrown. Note that percentages should not add up to more than 100% of a single pool.
If the sizes specified by data sets for any tier take exactly the entire CacheManager-level pool specified for that tier, a warning is logged. In this case, data sets that do not specify a size for that tier cannot use the tier, as nothing is left over.
Memory Store (Heap)
A size must be provided for the heap, either in the CacheManager (maxBytesLocalHeap only) or in each individual cache (maxBytesLocalHeap or maxEntriesLocalHeap). Not doing so causes an InvalidConfigurationException.
If a pool is configured, it can be combined with a heap setting in an individual cache. This allows the cache to claim a specified portion of the heap setting configured in the pool. However, in this case the cache setting must use maxBytesLocalHeap (same as the CacheManager).
In any case, every cache must have a heap setting, either configured explicitly or taken from the pool configured in the CacheManager.
Note:
Size-based cache capacity constraints at heap tier (maxBytesLocalHeap) is deprecated now and not expected to work from Java 17 onwards. Consider maxEntriesLocalHeap instead.
Off-Heap Store
Off-heap sizing can be configured in bytes only, never by entries.
If a CacheManager has a pool configured for off-heap, your application cannot add caches dynamically that have off-heap configuration — doing so generates an error. In addition, if any caches that used the pool are removed programmatically or through the Terracotta Management Console (TMC), other caches in the pool cannot claim the unused portion. To allot the entire off-heap pool to the remaining caches, remove the unwanted cache from the Ehcache configuration and then reload the configuration.
To use off-heap as a data tier, a cache must have overflowToOffHeap set to "true". If a CacheManager has a pool configured for using off-heap, the overflowToOffHeap attribute is automatically set to "true" for all caches. In this case, you can prevent a specific cache from overflowing to off-heap by explicitly setting its overflowToOffHeap attribute to "false".
Note that an exception is thrown if any cache using an off-heap store attempts to put an element that will cause the off-heap store to exceed its allotted size. The exception will contain a message similar to the following:
The element '[ key = 25274, value=[B@3ebb2a91, version=1, hitCount=0,
CreationTime = 1367966069431, LastAccessTime = 1367966069431 ]'
is too large to be stored in this offheap store.
Local Disk Store
The local disk can be used as a data tier, either for temporary storage or for disk persistence, but not both at once.
To use the disk as a temporary tier during BigMemory operation, set the persistenceStrategy to "localTempSwap", and use the maxBytesLocalDisk setting to configure the size of this tier. For more information about using the disk as a temporary tier, see Configuring Disk Store.
For information about using the disk store for data persistence, see Data Persistence Implementation.
Note that BigMemory Max distributed across a Terracotta Server Array cannot use the local disk.