The LRU ("Least Recently Used") mechanism functions with the desired behavior you've described.
From the product documentation:
===
The
lru_threshold parameter specifies the percentage of the maximum memory allocated to the StateServer service on the local host that must be in use before object reclamation is triggered. Once the StateServer service has allocated this amount of memory to store objects,
the least recently accessed objects that are marked as reclaimable will be removed as needed to keep memory consumption below the specified threshold. Object reclamation is concurrently triggered on all store hosts when any host reaches the threshold. The default value disables LRU object reclamation. Note that the maximum memory allocated to the StateServer service is determined by the max_memory parameter.
===
However, we do not recommend relying on the LRU mechanism for "day to day" normal operations. It is very important that the SOSS service always has adequate physical memory available. Please see
DEP-1 in our Best Practices (link) to assist you in calculating your minimum memory requirements. The LRU queue should only be used as a method to help avoid an out of memory situation. Even with LRU enabled, an out of memory situation may still occur if your application is loading data into the data grid faster than the LRU can evict older objects. In extreme situations, LRU may evict objects which your application expects to be present, which may result in sub-optimal performance or undesired behavior in your application's logic. For these reasons, we advise only using LRU for temporary severe surges of activity. For all other cases, you should specify an object timeout (absolute and sliding timeouts are available) or explicitly remove objects from the data grid when they are no longer needed.
Additionally, your
max_memory parameter of 20000 corresponds to only
20 MB. This value is exceedingly low. If the StateServer service is configured to use one replica, that limits your available storage to a theoretical maximum of
10 MB, but the StateServer service maintains internal metadata of each object which adds some overhead. A vast majority of our customers do not even configure the
max_memory parameter (instead relying on the default behavior of 80% of the physical memory available at service startup), but those who do often specify an upper limit measured in gigabytes (GB), with a few use cases in the several hundreds of megabytes (MB) range.
