How big maxElementsInMemory for Ehcache file?

[Pierre Zurmely]

Hello,

I am administrating a Stash service, and I have the warning:

2014-05-12 14:14:16,917 WARN [scheduler_Worker-8] o.h.c.e.i.s.AbstractReadWriteEhcacheAccessStrategy HHH020008: Cache[com.atlassian.crowd.model.user.InternalUser] Key[com.atlassian.crowd.model.user.InternalUser#3391439] Lockable[(null)]

I have already applyed the solution here:

https://confluence.atlassian.com/display/STASHKB/A+soft-locked+cache+entry+was+expired+by+the+underlying+Ehcache

My maxElementsInMemory is already set to 1000.

Do I have to make it bigger? How big? How does this scale?

Thanks in advance for your help,

Regards,

Pierre

[CelsoA · Accepted solution]

Hi Pierre,

According with ehcache documentation when the maximum number of elements in memory is reached, the least recently used ("LRU") element is removed. Used in this case means inserted with a put or accessed with a get. If the overflowToDisk cache attribute is false, the LRU Element is evicted. If true, it is flushed asynchronously to the DiskStore.

Because the memory store has a fixed maximum number of elements, it will have a maximum memory use equal to the number of elements multiplied by the average size. When an element is added beyond the maximum size, the LRU element gets pushed into the DiskStore. While we could have an expiry thread to expire elements periodically, it is far more efficient to only check when we need to. The tradeoff is higher average memory use. The expiry thread keeps the disk store clean. There is hopefully less contention for the DiskStore's locks because commonly used values are in the MemoryStore. We mount our DiskStore on Linux using RAMFS so it is using OS memory. While we have more of this than the 2GB 32 bit process size limit it is still an expensive resource. The DiskStore thread keeps it under control. If you are concerned about cpu utilisation and locking in the DiskStore, you can set the diskExpiryThreadIntervalSeconds to a high number - say 1 day. Or you can effectively turn it off by setting the diskExpiryThreadIntervalSeconds to a very large value.

Regards,

Celso Yoshioka

[Daniel R]

These warning are known behavior in Stash and tend to happen when the Crowd user management component syncs with an external user directory and cycles through all the users quickly (thus evicting some users that may be needed in other requests operating at the same time). If you ignore these warnings then Stash will need to do make some extra calls to the database to retrieve user information. We do not believe these extra database calls would materially impact the performance of your Stash instance.

Also, Stash 3.2+ no longer uses Ehcache. The default limit for the new caching framework is 2000 for both InternalUser and InternalUser.credentialRecords.