How big maxElementsInMemory for Ehcache file?


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:

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,



2 answers

1 accepted

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.


Celso Yoshioka

0 votes
Daniel Rohan Atlassian Team Oct 28, 2014

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.





Suggest an answer

Log in or Sign up to answer
Community showcase
Published Mar 14, 2019 in Bitbucket Pipelines

Building a Bitbucket Pipe as a casual coder :  #!/bin/bash source "$(dirname "$0")/" enable_debug extra_args="" if [[ "${DEBUG}" == "true" ]]; then extra_args="--verbose" fi # mandatory variables R...

250 views 0 12
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you