Documentation
Rate This Document
Findability
Accuracy
Completeness
Readability
SubmitClose

Tuning Process

Prerequisites

  • The server and OS are running properly.
  • An SSH remote login tool has been installed on the local PC.
  • The Java program to be tuned is stored in the server and GC logging is started.

Procedure

  1. Perform real-time profiling on the program. Go to the GC Logs tab page.

    Click Collect GC Log to obtain and parse the logs.

    Figure 1 GC log analysis
  2. Tune the issue "GC caused by metaspace expansion".
    Figure 2 Tuning suggestions

    In JDK 8 and later versions, the permanent generation (PermGen) is removed and replaced by metaspace which uses the local memory to store the metadata information. Continuous metaspace garbage collection means that memory leaks may have occurred due to classes or class loaders, or the metaspace size is inappropriate.

    After checking the code based on the tuning suggestions, it is found that the code cyclically and dynamically creates and loads classes. To address this issue, you can reduce the number of loops to reduce class loading, or set the classes to the singleton pattern to avoid repeated invoking.

    Figure 3 Case details

    For cases where code tuning cannot be performed, analyze the causes and check whether the number of GC times and time proportion generated by metadata are high. If you want to reduce the values, set the -XX:MetaspaceSize parameter to a larger value. Reduce the GCs caused by capacity expansion.

    Figure 4 GC causes
  3. Tune the issue "GC caused by humongous object collection".
    Figure 5 Tuning suggestions

    Any object that occupies more than half a region size is considered a humongous object. G1 finds a contiguous set of free regions to store humongous objects. If there is no enough contiguous free space, G1 starts a full GC to compress the Java heap space. After humongous objects are allocated, the corresponding regions do not store other objects, which wastes space. You can increase the value of -XX:G1HeapRegionSize to reduce full GCs caused by insufficient space for humongous objects and improve memory usage.

    Figure 6 GC causes

    Based on the GC cause analysis, check whether the situation is improved according to the percentage of GCs triggered by G1 Humongous Allocation.

  4. Tune the issue "Full GC occurred".
    Figure 7 Tuning suggestions

    When the space is about to be used up or the allocation speed cannot catch up with the reclamation speed, a full GC is triggered. In this case, the performance may be insufficient. In addition to checking whether the program can be tuned or improving the machine performance (by increasing the memory and improving the CPU performance), you can try to adjust related parameters to improve the GC efficiency and reduce the possibility of full GCs.

    1. Increase the size of the heap memory (Xmx) so that G1 has more time to complete concurrent marking.
    2. Increase the value of -XX:ConcGCThreads to increase the number of concurrent marking threads.
    3. Increase the value of -XX:G1ReservePercent (10% by default) to increase the memory space required by G1 during IHOP analysis.
    4. Set -XX:-G1UseAdaptiveIHOP to disable the adaptive IHOP analysis mechanism. Set -XX:InitiatingHeapOccupancyPercent to a smaller value (45 by default) to trigger the GC marking period in advance.

    You can check the detailed analysis of GC activities to view the full GC statistics. Compare the full GC statistics before and after the tuning to determine whether the average full GC interval is improved.

  5. Tune the issue GC "Full GC caused by System.gc()".
    Figure 8 Tuning suggestions

    You are not advised to explicitly call System.gc() because it triggers a full GC. Check and remove related code or use -XX:+DisableExplicitGC to ignore the calling of System.gc(). If it is a system or framework-level call and cannot be disabled, you can enable -XX:+ExplicitGCInvokesConcurrent to change a full GC to Initial-mark.

    To verify the tuning effect, collect logs of the tuned program and check whether tuning suggestions on System.gc() are displayed. Alternatively, view the GC logs to check whether the logs triggered by System.gc() exist. If yes, check whether the phase is Initial-mark.

Summary

In Java, it is difficult to locate faults and provide solutions based on GC logs. You can check the code or modify the startup parameters based on the tuning suggestions provided after the GC logs are parsed. Then restart the system. After a period of time, check whether the GC efficiency is improved by comparing the log throughput, average GC pause time, and average time interval in GC refined activity analysis.

GC logs need to be tuned only when the code cannot be further tuned. If the device performance cannot support services and no obvious improvement is observed after the program is tuned based on the tuning suggestions, upgrade the device configuration to meet service requirements.