Chapter 2. Set Up Eviction
2.1. About Eviction
Eviction is the process of removing entries from memory to prevent running out of memory. Entries that are evicted from memory remain in configured cache stores and the rest of the cluster to prevent permanent data loss. If no cache store is configured, and eviction is enabled, data loss is possible.
Red Hat JBoss Data Grid executes eviction tasks by utilizing user threads which are already interacting with the data container. JBoss Data Grid uses a separate thread to prune expired cache entries from the cache.
Eviction occurs individually on a per node basis, rather than occurring as a cluster-wide operation. Each node uses an eviction thread to analyze the contents of its in-memory container to determine which entries require eviction. The free memory in the Java Virtual Machine (JVM) is not a consideration during the eviction analysis, even as a threshold to initialize entry eviction.
In JBoss Data Grid, eviction provides a mechanism to efficiently remove entries from the in-memory representation of a cache, and removed entries will be pushed to a cache store, if configured. This ensures that the memory can always accommodate new entries as they are fetched and that evicted entries are preserved in the cluster instead of lost.
Additionally, eviction strategies can be used as required for your configuration to set up which entries are evicted and when eviction occurs.
See also: Eviction and Expiration Comparison
2.2. Eviction Strategies
2.2.1. Eviction Strategies
Each eviction strategy has specific benefits and use cases, as outlined below:
Table 2.1. Eviction Strategies
| || |
No eviction occurs.
This is the default eviction strategy in Red Hat JBoss Data Grid.
| || |
Least Recently Used eviction strategy. This strategy evicts entries that have not been used for the longest period. This ensures that entries that are reused periodically remain in memory.
| || |
Unordered eviction strategy. This strategy evicts entries without any ordered algorithm and may therefore evict entries that are required later. However, this strategy saves resources because no algorithm related calculations are required before eviction.
This strategy is recommended for testing purposes and not for a real work implementation.
| || |
Low Inter-Reference Recency Set eviction strategy.
LIRS is an eviction algorithm that suits a large variety of production use cases.
2.2.2. LRU Eviction Algorithm Limitations
In the Least Recently Used (LRU) eviction algorithm, the least recently used entry is evicted first. The entry that has not been accessed the longest gets evicted first from the cache. However, LRU eviction algorithm sometimes does not perform optimally in cases of weak access locality. The weak access locality is a technical term used for entries which are put in the cache and not accessed for a long time and entries to be accessed soonest are replaced. In such cases, problems such as the following can appear:
- Single use access entries are not replaced in time.
- Entries that are accessed first are unnecessarily replaced.
2.3. Using Eviction
2.3.1. Using Eviction
In Red Hat JBoss Data Grid, eviction is disabled by default. If an empty
eviction / element is used to enable eviction without any strategy or maximum entries settings, the following default values are used:
Strategy: If no eviction strategy is specified,
EvictionStrategy.NONEis assumed as a default.
size: If no value is specified, the
sizevalue is set to
-1, which allows unlimited entries.
2.3.2. Initialize Eviction
To initialize eviction, set the eviction element’s
size attributes value to a number greater than zero. Adjust the value set for
size to discover the optimal value for your configuration. It is important to remember that if too large a value is set for
size, Red Hat JBoss Data Grid runs out of memory.
The following procedure outlines the steps to initialize eviction in JBoss Data Grid:
Add the Eviction Tag
Add the eviction tag to your project’s cache tags as follows:
Set the Eviction Strategy
strategyvalue to set the eviction strategy employed. Possible values are
NONEif no eviction is required). The following is an example of this step:
<eviction strategy="LRU" />
Set the Maximum Size to use for Eviction
Set the maximum number of entries allowed in memory by defining the
sizeelement. The default value is
-1for unlimited entries. The following demonstrates this step:
<eviction strategy="LRU" size="200" />
2.3.3. Eviction Configuration Examples
Eviction may be configured in Red Hat JBoss Data Grid programmatically or via the XML file. Eviction configuration is done on a per-cache basis.
A sample XML configuration for is as follows:
<eviction strategy="LRU" size="2000"/>
2.3.4. Utilizing Memory Based Eviction
Red Hat JBoss Data Grid 7 introduced memory based eviction, allowing eviction of entries based on memory usage of the entries instead of the number of entries. This can be particularly useful if the entries vary in size.
Only keys and values that are stored as primitives, primitive wrappers (such as
java.lang.String instances, or an
Array of these values may be used with memory based eviction.
Due to this limitation if custom classes are used then either
store-as-binary must be enabled on the cache, or the data from the custom class may be serialized, storing it in a byte array.
Compatibility mode prevents serialization into byte arrays, and as such these two features are mutually exclusive.
Eviction Strategy Limitations
Memory based eviction is only supported with the
LRU eviction strategy.
Enabling Memory Based Eviction
This eviction method may be used by defining
MEMORY as the eviction type, as seen in the following example:
<local-cache name="local"> <eviction size="10000000000" strategy="LRU" type="MEMORY"/> </local-cache>
2.3.5. Eviction and Passivation
To ensure that a single copy of an entry remains, either in memory or in a cache store, use passivation in conjunction with eviction.
The primary reason to use passivation instead of a normal cache store is that updating entries require less resources when passivation is in use. This is because passivation does not require an update to the cache store.