1 Reply Latest reply on Aug 18, 2016 6:28 AM by Radim Vansa

    Eviction based on Runtime.freeMemory()

    Oliver Plohmann Newbie



      we use Infinispan basically for preloading data from the database to cache it in Infinispan for faster access times. About 90+ % is read-only static data that remains in Infinispan and is not evicted. What we would need is a way to evict the remaining data in case that memory is about to run full. So basically, if Runtime.freeMemory() falls below a threshold value non-static data should be evicted using LRU.


      Now, there is no such eviction strategy in Infinispan. Question is whether it would make sense to add it. But I don't really want to start a discussion about that. I rather want to check out whether such an eviction startegy can be implemented on the client side by the Infinispan end-user. Let's say on all nodes in my Infinispan cluster I have some demon that periodically checks free memory and keeps a list of most recently used cache keys. If in the cluster free memory falls below a threshold LRU cache entries are removed.


      Problem is here that on the client side you don't know on which node in the cluster some cache entry resides. So you don't know whether freeing memory will be effective. There are lots of other similar issues that need to be considered. If anyone has some knowledge what has to be considered or has some ideas how to do this, I would be thankful if some lines of text could be dropped on this ;-).


      Cheers, Oliver

        • 1. Re: Eviction based on Runtime.freeMemory()
          Radim Vansa Master

          Such daemon would probably evict the entries quite soon, as JVM's heap is about to fill up, find out that there's ton of garbage and release it. Runtime.freeMemory() does not tell you the  total size of living objects. That's why Infinispan implements the memory-based eviction, estimating the size entries really occupy in memory, and allows you to set the max total size you'd like to keep in the memory (you have already set -Xmx and -Xms, so make the actively-hold size about 50% to give JVM some space - and don't forget how many backup copies the nodes hold).


          If you want to find it out the hard way you can use cache.getAdvancedCache().getDistributionManager() to find out which entries are where, and/or use cache.withFlags(Flag.CACHE_MODE_LOCAL) to execute operations that don't span to another nodes (e.g. if you want to iterate through local entries).