7.16.3 Tuning to suppress the occurrence of Full GC
- Organization of this subsection
(1) Concept of suppressing Full GC
|
|
Full GC occurs when the used size of the Tenured area increases to the point where no more Free regions are available.
The following figure illustrates tuning to suppress occurrence of Full GC.
|
|
The key to suppressing the occurrence of Full GC is to control the increase in the used size of the Tenured area. We can therefore consider the following two approaches to suppressing the occurrence of Full GC:
-
Reduce the number of objects that are moved to the Tenured area
-
Collect objects in the Tenured area that are no longer needed
If the Survivor area is full, then use the first approach to tuning. If the Survivor area is not full, then use the second approach. For details about the first approach, see 7.16.3(3) Tuning the size of the Survivor area. For details about the second approach, see 7.16.3(4) Tuning to increase the regions selected by mixed GC. After finishing the tuning process, repeat system verification to confirm whether the system requirements are now satisfied.
(2) When an application creates numerous large objects
An application creating numerous large objects can make it impossible to secure enough contiguous regions and trigger Full GC. Because G1 GC manages memory at the region level, it is not suited to systems that create numerous large objects. If your system creates numerous objects and this triggers Full GC, you need to modify your applications to prevent this from happening.
You can identify large objects by looking for the Humongous label in the log file.
[VG1]<Wed Jan 15 12:51:32 2014>[Full GC 130443K/131072K(131072K)->55462K/56320K(131072K), 2.3265610 secs][Status:-][G1GC::Eden: 0K(43008K)->0K(43008K)][G1GC::Survivor: 0K->0K][G1GC::Tenured: 131072K->56320K][G1GC::Humongous: 1024K->0K][G1GC::Free: 0K->74752K][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:ObjAllocFail][RegionSize: 1024K][Target: 0.2000000 secs][Predicted: 0.0000000 secs][TargetTenured: 0K][Reclaimable: 0K(0.00%)][User: 2.1700000 secs][Sys: 0.0000000 secs][IM: 277185K, 261856K, 44544K][TC: 1168][DOE: 0K, 0][CCI: 5808K, 49152K, 5952K]
(3) Tuning the size of the Survivor area
The approach that reduces the number of objects that are moved to the Tenured area works by collecting objects while they are still in the Survivor area. When there is no more free space in the Survivor area, the overflow triggers a save process that promotes objects with short lifespans to the Tenured area. By increasing the size of the Survivor area, you can collect objects with short lifespans while they are still in the Survivor area, reducing the number of objects moved to the Tenured area.
When to exhausted appears in the log entry, this indicates that the Survivor area has overflowed. In this case, use the -Xmx option or the -XX:SurvivorRatio option to increase the size of the Survivor area.
[VG1]<Wed Jun 12 11:21:10 2013>[Young GC 899070K/899072K(1048576K)->501755K/501760K(1048576K), 0.0931560 secs][Status:to exhausted][G1GC::Eden: 389120K(389120K)->0K(397312K)][G1GC::Survivor: 41984K->41984K][G1GC::Tenured: 459776K->459776K][G1GC::Humongous: 2048K->2048K][G1GC::Free: 609536K->607232K][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:G1EvacuationPause][RegionSize: 1024K][Target: 0.2000000 secs][Predicted: 0.2495800 secs][TargetTenured: 0K][Reclaimable: 0K(0.00%)][User: 0.0156250 secs][Sys: 0.0312500 secs][IM: 729K, 928K, 0K][TC: 509][DOE: 16K, 171][CCI: 2301K, 49152K, 2304K]
The following explains how to use each option to tune the size of the Survivor area.
-
-Xmx option
You can increase the size of the Java heap area by specifying a larger value in this option. By increasing the overall size of the Java heap area, you also increase the size of Survivor area. However, increasing the maximum size of the Java heap area also increases the minimum and maximum values that govern the extent to which the New area can be resized. Because this increases the minimum pause time, after completing the tuning process, you must verify again whether the system meets the system requirements.
-
-XX:SurvivorRatio option
By specifying a smaller value in this option, you can increase the proportion of the reserved New area that is allocated to the Survivor area. However, because this approach results in a smaller Eden area, it has the secondary effect of making young GC and mixed GC more likely to occur. Therefore, after completing the tuning process, you must verify again whether the system meets the system requirements.
- Note:
-
Another approach to increasing the size of the Survivor area is using the -XX:NewRatio, -XX:NewSize, or -XX:MaxNewSize option to increase the size of the New area. However, because this limits the extent to which the New area can be resized after GC, we do not recommend that you take this approach.
(4) Tuning to increase the regions selected by mixed GC
To increase the regions targeted by mixed GC, you can have each instance of mixed GC target more regions, or increase the total number of target regions by triggering mixed GC more often. The first approach lowers responsiveness, and the second approach reduces throughput. Select the appropriate tuning method according to the system requirements.
-
-XX:MaxGCPauseMillis option
You can increase the target pause time by specifying a larger value in this option. Mixed GC targets the New area and part of the Tenured area. GC targets the Tenured area when there is sufficient leeway in the predicted pause time relative to the target pause time after targeting the New area. By increasing the target pause time, you can increase the number of Tenured regions targeted during a single instance of mixed GC. However, this approach extends the GC pause time, reducing the responsiveness of the system.
-
-XX:ConcGCThreads option
Increasing the value specified for this option increases the number of threads used for CM. CM must have completed before mixed GC can occur, and you can complete CM more quickly by increasing the number of threads. This increases the frequency with which mixed GC occurs, which has the effect of increasing the total number of targeted regions. However, because this method increases the number of processing threads working in parallel with the application threads, the throughput of the system is reduced.
You cannot specify a value for the number of CM threads that is larger than the number of threads used for evacuation processing. Therefore, when you increase the value of the -XX:ConcGCThreads option, you must also increase the value of the -XX:ParallelGCThreads option.