Mark,
On 1/20/22 04:18, Mark Thomas wrote:
On 20/01/2022 08:54, Olaf Kock wrote:
My rule of thumb is: The
more memory there is to be claimed in GC, the longer a full GC run
takes.
Nope.
The time a GC run takes is proportional to the size of objects in memory
that do not need to be GC'd. GC walks the active object tree so it is
the active objects that matter.
Doesn't this depend upon which "space" is being cleaned? The young
generations (by whatever name, depending upon the GC engine being used)
work this way, but the "older" generations usually have to be "cleaned"
(rather than "prompted and abandoned"). But of course, the older
generations typically have far less garbage to be collected than the
younger generations which have large numbers of allocations and
deallocations all the time.
Generally, the more memory you give the JVM to work with, the lower the
impact of GC for both pauses and throughput.
A rule of thumb I have seen in the past (may be out of date for current
JVMs) is that the JVM needs roughly 5x the steady state memory
requirements for GC to work most efficiently.
That's an interesting anecdote; it seems like a very large factor to me.
Something else Olaf said is worth repeating: setting -Xms and -Xmx to
the same value for a server process is a good idea, otherwise the memory
spaces will have to be periodically re-organized and expanded which just
waste resources.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
