Your heap is big enough when your GC performance is good enough. Garbage collectors have improved tremendously over the years. My rule of thumb used to be that I wanted the app to spend less than 1% of time in GC, but that’s actually easy to achieve these days as long as your heap is big enough. I can’t tell you whether it needs to be 1GB or 10GB. You’ll have to experiment. It’s very common to have GC overhead well below 1% now. (That’s 600ms per 60000ms.)
From: Mark Thomas <ma...@apache.org> Sent: Tuesday, April 22, 2025 2:38 AM To: users@tomcat.apache.org Subject: Re: Best practices to set heap memory ͏On 21/04/2025 17: 49, Christopher Schultz wrote: > Ramesh, > > On 4/21/25 1: 06 AM, Ramesh B R wrote: >> How to decide on heap memory size? >> is it 25% of total memory? or 50% total memory? >> >> What is the ideal ZjQcmQRYFpfptPreheaderEnd On 21/04/2025 17:49, Christopher Schultz wrote: > Ramesh, > > On 4/21/25 1:06 AM, Ramesh B R wrote: >> How to decide on heap memory size? >> is it 25% of total memory? or 50% total memory? >> >> What is the ideal value (in %) for heap memory ? > > Only you can answer that question about your own application environment. > > The percentage of total memory is completely irrelevant if you ask me. > Presumably, you have a server so that you can serve requests for the > application. If you have other services on the same server, then you > will have to balance the memory requirements of each service against the > others. > > If it's a single-service server then I would dedicate ALL of the > available memory to that service. That doesn't mean 100% (or 90% or 80%) > dedicated to heap memory, as there is a lot of memory usage in Java that > is not accounted for by the heap. > > I would start from the other end: what does your application actually > need under typical (and worst-case) load scenarios. If your application > doesn't need a lot of heap space, then I wouldn't bother paying for it, > whether you are buying physical RAM chips or renting them from a cloud > provider. > > If you have other requirements, such as minimal application pauses, or > transaction times where GC could impact your ability to meet certain > goals, then your heap space may be of critical concern. Mot modern GCs > benefit from more memory. Remember that the "cost" of the garbage > collector is related to the number of things that need to stay in memory > rather than the number of things that need to be collected. So running > GC on a large heap is no more expensive than it is running on a small > heap, assuming the same load scenarios. Big +1 to all of the above. A long time ago I attended some talks of Java GC, memory usage and performance. A very quick summary is: - Memory footprint, throughput and latency. Pick any two at the expense of the third. - Look at your application's steady state memory usage. It should be a sawtooth. Take the minimum value of the sawtooth and multiply it by 5. Allocate that much memory to the Java heap. That should give GC the room it needs to operate efficiently. That exact multiplier may not apply to more modern GC algorithms. Every application is different. You'll need to do some testing to find out what works best for your application. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org> For additional commands, e-mail: users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org>