Maximum Memory Allocated
Good afternoon,
Is there a maximum amount of memory we can allocate to Cascade, or is the only rule of thumb not to exceed 3/4 of the system RAM?
Thanks!
Discussions are closed to public comments.
If you need help with Cascade CMS please
start a new discussion.
Keyboard shortcuts
Generic
? | Show this help |
---|---|
ESC | Blurs the current field |
Comment Form
r | Focus the comment reply box |
---|---|
^ + ↩ | Submit the comment |
You can use Command ⌘
instead of Control ^
on Mac
Support Staff 1 Posted by Tim on 26 Jan, 2015 07:11 PM
Hi Justin,
There isn't any hard maximum, but it's not always best to set a huge maximum heap size (because that can lead to longer garbage collections for the JVM). How much RAM are you currently allocating and how much total RAM is available on your application server?
Are you currently seeing any Out of Memory errors in the log files in your instance or are you just curious about increasing the allocation?
Thanks!
2 Posted by Justin Rogers on 27 Jan, 2015 08:51 PM
Good afternoon Tim,
We are currently only allocating 4GB, out of a total 16GB on the server. We aren't getting any Out of Memory errors in the log, we are just trying to make sure the system has enough resources for any potential spikes in activity so (hopefully) we can avoid any errors before they happen.
In your experience, at what point does the extra memory start to bog down the garbage collection? Will leaving the initial heap size to something smaller help to alleviate this at all, or is it better practice to keep the initial and maximum heap sizes closer together?
Also of note (I meant to specify this in the initial post) but we are using 64 bit Java on this instance of Cascade, so we don’t have to worry about running into the ~1400MB maximum that comes with using 32 bit Java.
Thank you!
Justin Rogers
Web Team
Office of Information Technology
Florida Department of Health
4052 Bald Cypress Way B05
Tallahassee FL 32399-1733
(850) 245-4444 xtn. 3203
[email blocked]<mailto:[email blocked]>
http://www.floridahealth.gov
_________________________________
Mission: To protect, promote and improve the health of all people in Florida through integrated state, county, and community efforts.
Vision: To be the Healthiest State in the Nation.
Please note: Florida has a very broad public records law. Most written communications to or from state officials regarding state business are public records available to the public and media upon request. Your email communication may therefore be subject to public disclosure.
Support Staff 3 Posted by Tim on 27 Jan, 2015 09:06 PM
Thanks for the additional information, Justin.
It's difficult to say as it will really depend on your implementation along with the number of users in your system (along with what they are doing at any given time). In general, I think it's best to keep the initial and maximum heap sizes the same, but you may need to tune these settings once you get above 6GB or so for the heap size (by setting the Xms a bit lower than the Xmx). The scenario you want to avoid is where the JVM will pause everything in order to do a full garbage collection. This can happen if the heap is set to something much larger than it needs to be. So, I'd recommend monitoring the instance to see if you are ever running out of memory altogether over a span of a couple of weeks. If you aren't, and you aren't noticing any performance issues in the system, you should be fine with your current settings.
If you feel that memory issues might be causing performance problem in your instance, it's possible to enable garbage collection logging which would provide us with more information as to how often garbage collections might be occurring (along with how successful they are). We can go that route if you begin running into issues.
We include a monitoring tool (Java Melody) with the application beginning with version 7.12.3. This may help assist you all in seeing how your instance is performing over periods of time.
I hope this helps!
Thanks
Justin Rogers closed this discussion on 16 Mar, 2015 12:48 PM.