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