[infinispan-dev] A couple of general eviction questions

[Manik Surtani]

On 18 Feb 2010, at 21:02, Alex Kluge wrote:

> Hi,
> 
>  I have a couple of general questions about eviction.
> 
> Why is it an out of band process? From http://community.jboss.org/wiki/infinispan-eviction it looks like the eviction thread is trimming the data container to its size limit.  I created an interceptor and used a clock mechanism (as in clock cache) to determine when elements should be removed from the cache. It is positioned just after the mvcc locking and if there are enough keys in a node, then one is removed. The performance impact here is reasonable, but the clock is much faster than a strict LRU. It also removes the possibility of the OOM when you don't run the eviction thread frequently enough. The LIRS implementation also looks reasonably fast, and so could be in lined into the cache access. With a flatter cache does it make sense for eviction to be inline?

It does, and I'll let Vladimir comment on where eviction is going in 4.1.

What you see in 4.0 is essentially the old JBoss Cache design (eviction thread, etc) just so we gained the features with minimal effort.  

> Has any thought been given to placing an explicit limit on the amount of memory that is used? You can dynamically fetch the old generation max size at startup, then set a notification on the corresponding mbean to notify you when a threshold is exceeded. As long as memory usage remains above a limit, entries can be evicted from the cache. Once it falls below the limit, the check no longer needs to be made until the notification triggers again. This is a bit course as it looks at the total memory in use, but Java doesn't have a sizeof operator. I went down this path because the general eviction path can run into issues if the maxentries is too large.

Yes, there are issues around using the JVM size, as you mentioned, although this could be a valid setup for certain use cases (such as dedicated storage nodes where the VM just contains an Infinispan instance).  Another approach is to ensure lazy deserialization is used, which wraps all keys and values as MarshalledValues and stores binary (byte[]) representations.  This makes it easy to calculate the size of user content in memory.  We would need to think about how either of these additional high-water marks can be used, in addition to a simpler "numEntries", without changing what we've done for 4.1 too much.  Vladimir, any thoughts here?  

Cheers
Manik
--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org