CacheBox and missing evictions

I may have this wrong but I want to verify that I understand what's
going on with my newly deploy caching system. I have an "Inventory"
cache, that allows for 10,000 items. In watching the CacheBox Monitor
though, I never see the cache get that high. My assumption is this is
due to a memory issue. At around 3,500 items, my JVM starts getting
pretty full. At this point, I will see the cache drop to around 2,500
items, but the CacheBox Monitor still shows 0 evictions.

Where are these objects going? Is the Cache clearing out items to
ensure that the JVM doesn't get too full? If so, is it safe to assume
it's following the LRU model of dropping those items (since that's how
my cache is configured)?

If my assumptions are correct, then it looks like it's time to take
advantage of that 64-bit system I'm sitting on, and I need to increase
the RAM in the box. If not, then I need to figure out why items are
dropping out of the cache without actually being evicted.

Thanks,

Dan

Dan,

Your assumptions sound right, but, to answer your question accurately I need you to share the CacheBox config.

Also, as you approach your x64 system conventional wisdom says not to give your JVM instance more than 4gb of memory (most people say 3gb). Beyond that and you may find the garbage collection activities can take enough time that they cause negative performance. If you plan on using more than 3gb of memory you may want to explore out of process caching.

Thanks,

Aaron Greenlee
http://aarongreenlee.com/

Thanks for the reply Aaron. Here's the config I'm using:

      defaultCache = {
        objectDefaultTimeout = 120,
        objectDefaultLastAccessTimeout = 30,
        useLastAccessTimeouts = true,
        reapFrequency = 2,
        freeMemoryPercentageThreshold = 0,
        evictionPolicy = "LRU",
        evictCount = 1,
        maxObjects = 10000,
        objectStore = "ConcurrentSoftReferenceStore",
        // This switches the internal provider from normal cacheBox to
coldbox enabled cachebox
        coldboxEnabled = false
      },

Also, I'll definitely keep the 3-4 GB limit in mind. I didn't plan on
going any higher than 4GB.

Dan

“ConcurrentSoftReferenceStore” is the secret there. CacheBox creates a SoftReference which allows the JVM remove these objects from memory when memory gets right. Below, please find an excerpt from the JavaDocs and a link to more information:

"Soft reference objects, which are cleared at the discretion of the garbage collector in response to memory demand. Soft references are most often used to implement memory-sensitive caches.

Suppose that the garbage collector determines at a certain point in time that an object is softly reachable. At that time it may choose to clear atomically all soft references to that object and all soft references to any other softly-reachable objects from which that object is reachable through a chain of strong references. At the same time or at some later time it will enqueue those newly-cleared soft references that are registered with reference queues.

All soft references to softly-reachable objects are guaranteed to have been cleared before the virtual machine throws an OutOfMemoryError. Otherwise no constraints are placed upon the time at which a soft reference will be cleared or the order in which a set of such references to different objects will be cleared. Virtual machine implementations are, however, encouraged to bias against clearing recently-created or recently-used soft references.

Direct instances of this class may be used to implement simple caches; this class or derived subclasses may also be used in larger data structures to implement more sophisticated caches. As long as the referent of a soft reference is strongly reachable, that is, is actually in use, the soft reference will not be cleared. Thus a sophisticated cache can, for example, prevent its most recently used entries from being discarded by keeping strong referents to those entries, leaving the remaining entries to be discarded at the discretion of the garbage collector."

Gotcha, so in this case, it's "a good thing". And they're not showing
as evictions, because the JVM is removing them instead of CacheBox,
correct? So it's time to talk to my hardware guys and get an extra
DIMM or two into those boxes.

Thanks Aaron,

Dan

Yes, you are relying on cachebox’s memory awareness. They won’t appear as evictions but as JVM garbage collections in the report. This is good, as it allows the best possible utilization of your memory without collapsing, in theory. I always suggest using the soft reference store as it provides better stability but in turn you receive a more dynamic cache and times are never guaranteed. So you have to decide what you prefer.

If you have enough memory, I would suggest using the normal concurrent store. If not, maybe the soft reference store.

Luis F. Majano
President
Ortus Solutions, Corp
www.ortussolutions.com

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

Social: twitter.com/lmajano facebook.com/lmajano

That's perfect, and things are working well at the moment. I also have
an order in for more RAM on our servers to increase the JVM size, so
things are only going to get better from here on out. :slight_smile:

Dan