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 (demo) to be tuned is running on the target server.

Procedure

1. Download the demo program. For details about how to package and deploy the program, see README.md.
2. Perform real-time profiling on the program and switch to the GC tab page.
   In the browser, invoke http://{ip}:9118/gctest/bigdata, which needs to be accessed for multiple times.

   Figure 1 GC tab page - 1
   

   It is found that some GC events are caused by the allocation of humongous objects.

3. Perform sampling profiling on the program and switch to the GC tab page.

   View the tuning suggestions.

   Figure 2 GC tab page - Tuning Suggestions
   
4. Switch to the Old-Generation Objects page on the Memory tab page.

   During sampling profiling, the http://{ip}:9118/gctest/bigdata API needs to be invoked for multiple times in the browser.

   Figure 3 Old-Generation Objects
   

   Under certain circumstances, if the lifecycle of humongous objects is long, you can collect the object information on this tab page and obtain a report to learn about the object sizes and the program region size. It can be concluded that the collected humongous objects are created in the same thread. The humongous objects are int[] objects with the size of 6 MiB. You can search for the code based on the stack to check the specific logic.

5. Perform real-time profiling on heap dump.
   If a humongous object cannot be directly collected through sampling profiling, you can find the corresponding clue from the heap dump analysis based on the region size. Search for the suspicious classes that occupy a large number of heaps in the histogram.

   Figure 4 Heap Dump
   
6. View all objects of the suspicious classes.
   Figure 5 Heap Dump
   
   Figure 6 List of all objects
   

   It is found that int[] is frequently allocated and the size is 6 MiB, which meets the requirements of humongous objects. Continue the locating process.

7. Check the dominator tree for clues.
   Figure 7 Dominator tree
   

   In the dominator tree, it is found that the retained heap size of a thread is similar to the size of the retained heap size of int[] in the histogram.

   Figure 8 Unfolded dominator tree
   

   It is found that a list in the thread holds the created humongous object. Check the path from int[] to GC Roots.

   Figure 9 Path entry from int[] to GC roots
   
8. Locate the program code.

   Find the specific code based on the class name GcTestController, the humongous object int[], and the humongous object List provided by real-time profiling.

   Figure 10 demo
   
9. Check the optimized Java program.

   In this demo, this problem is solved by increasing the region size.

   Figure 11 Overview tab page
   
   Figure 12 GC tab page
   

Summary

In this practice, sampling profiling and heap dump analysis are performed to locate the allocation of humongous objects in the code, and the problem is solved by increasing the region size. However, in actual services, you are advised to preferentially adjust the code logic to solve the problem and avoid allocation of humongous objects to reduce the JVM pressure. If the default region size does not suit the program, you can increase the region size as required.

When tuning other programs, you need to perform tuning operations based on the analysis results collected by the Java Profiler and the corresponding tuning suggestions. For details about the tuning roadmap, see this practice.