BigMemory 4.3.10 | Product Documentation | BigMemory Max Administrator Guide | Automatic Resource Management | Eviction
 
Eviction
All data is kept in memory, and the TSA runs evictions in the background to keep the data set within its limitations. Eviction of entries from the data set reduces the amount of data before the memory becomes full. The criteria for an entry to be eligible for eviction are:
*It is not on a Terracotta client (L1).
*It is not pinned to a Terracotta server.
*It is held in a cache backed by a System of Record (SOR).
Note:
Store vs. Cache - BigMemory's in-memory data is treated as a "store" when BigMemory owns the data, and as a "cache" when the data also resides in a System of Record (SOR). Generally, data that is created by BigMemory and run-time data created by your application are examples of data that is treated as a store. The TSA does not evict data stores because they are the only or primary records. The TSA can evict cached data because that data is backed up in an SOR. Distinctions in data structures are handled automatically.
Eviction is done by the following evictors, which work together in the background:
1. The periodic evictor is activated on an as-needed basis. It removes expired entries based on TTI/TTL settings. The Server Expiration Rate graph in the TMC shows the activity of the periodic evictor.
2. The resource-based evictor is activated by the periodic TTI/TTL eviction scheduler, as well as by resource monitoring events. This evictor continuously polls BigMemory stores to check current resource usage. At approximately 10% usage of the disk as well as dataStorage and offheap sizes (configured in the tc-config.xml file), it starts looking for TTI/TTL-expired elements to evict. At approximately 80% usage, it evicts live as well as expired elements. If a monitored resource goes over its critical threshold, this evictor will work continually until the monitored resource falls below the critical threshold.
This evictor monitors two off-heap thresholds -- used space and reserved space. Resource eviction is triggered if either the reserved or used space is above its threshold. Once resource eviction has started, both used and reserved spaces must fall below their respective thresholds before resource eviction ends.
The Offheap Usage graph in the TMC provides the following information:
*Off-heap Max is the configured offheap size
*Off-heap Reserved represents usage of the space that is reserved for the system
*Off-heap Used represents the amount of off-heap BigMemory that is in use
The Data Storage Usage graph in the TMC shows the configured dataStorage size and the amount in use. This usage includes off-heap and hybrid storage combined. (BigMemory Hybrid allows for a mix of a solid-state drive (SSD) with DRAM-based offheap storage.)
3. The capacity-based evictor is activated when a cache goes over its maximum count (as configured with maxEntriesInCache ), plus an overshoot count, and it attempts to bring the size of the cache to the max capacity. The maxEntriesInCache attribute must be present in the Ehcache configuration (do not include maxEntriesInCache in your configuration if you do not want the capacity evictor to run). If maxEntriesInCache is not set, it gets the default value 0, which means that the cache is unbounded and will not undergo capacity eviction (but periodic and resource evictions are still allowed).
The Server Eviction Rate graph in the TMC shows the activity of the resource and capacity evictors.