Tuning concurrent garbage collection
This is part one of our GC mini series, all information relates to
the now default G1 garbage collector. Most
people would immediately run an upgrade promising 5% performance
gain, but neglect to do some basic GC tuning, that might even
return better results.
The concurrent GC threads (G1 Conc#* and G1 Refine#*) are often
overlooked as they run parallel to JVM execution and seem to have
no negative impact. For I2P they should not need much more than 1%
total process time together.
They have to work hard in two cases:
1) Java heap size too small. In a test with BiglyBT,
32bit, 96 MB heap, classic UI, G1Conc#* totalled 20% CPU. Raising
the heap to 160 MB brought that down to just over 1%.
You will want to set this using "-Xmx***M" or
"wrapper.java.maxmemory=***".
2) Minimum heap size not set. We strongly recommend
setting the minimum size to the same value as the total heap size,
unless this way all concurrent apps would not fit into physical
memory.
By not doing so you instruct the JVM to do two things: Fight hard
to keep the heap size small by permanently cleaning stale objects
and continously resize the heap down to the lowest possible value.
That costs lots of CPU, usually several %CPU.
You will want to set this using
"-Xms***M" or "wrapper.java.initmemory=***".
<-- Back --> Next