Preface
GCEasy is a very easy-to-use tool for online analysis of GC logs. Open the official website and upload the gc logs directly. You can also compress and upload more on-site requirements.
JVM memory size (jvm memory size area)
JVM memory size, GCEasy shows the young generation, the old generation, and the meta space. The size allocated by the JVM and the peak size used during the running of the program.
From the information displayed by the JVM memory size, we can determine whether we need to do the following things.
- Do you need to modify the relevant configuration of JVM memory (-Xms, -Xmx, -Xmn...), for example, the peak value of the young generation and the old generation is much smaller than the allocated size, at this time we can appropriately reduce the memory setting.
- Do you need to adjust the ratio between the young generation and the old generation (-XX:NewSize(-Xns), -XX:MaxNewSize(-Xmn), -XX:SurvivorRatio=8). For example, the peak value of the old age is always smaller than the memory requested by the old generation. At this time, we can allocate a little more space to the young generation.
- Whether to modify the meta space (XX:MetaspaceSize, -XX:MaxMetaspaceSize) related settings.
The young generation, the old generation belongs to the heap area, and the meta space belongs to the non-heap area (the memory of the machine is directly connected to it)
Key Performance Indicators
Throughput represents the throughput
Latency represents the response time
Avg Pause GC Time Average GC time
Max Pause GC TIme Maximum GC time
Key Performance Indicators shows us the GC throughput (the proportion of application thread time to the total program time, the higher the better ), the average time consumption of each GC (recommended to be controlled below 50ms), the longest GC time, the number of GCs and the proportion of each time period.
In the information displayed by Key Performance Indicators, we need to pay attention to the following issues:
- Throughput, the percentage of time the application spends on non-GC (quotes the percentage spent on production tasks). So the higher the throughput, the better.
- The average time consumption of each GC. The smaller the better, it is recommended to be less than 50ms.
- GC takes the longest time. The smaller the better. If your application is a background program, and any request does not exceed 10 seconds, then the longest GC time can not exceed 10 seconds.
According to the memory tuning guidelines, among the above three optimization indicators, only two of the three can be selected at most
- If you want better throughput and latency, you need to sacrifice CPU consumption
- If you want better throughput and CPU consumption, you need to sacrifice latency.
- If you want better latency and CPU consumption, you need to sacrifice throughput
Interactive Graphs
Interactive Graphs shows
Heap after GC :
Heap usage after GC Heap before GC : Heap usage before GC
GC Duration : GC duration
Reclaimed Bytes : Memory size of garbage objects reclaimed by GC
Young Gen : Heap usage of young generation
Old Gen : Heap usage in the old age
Meta Space : Meta space usage
A & P : Heap memory allocation and promotion in each GC. The red line indicates how much memory (objects) in the young generation has been promoted to the old generation during each GC.
The first part is Heap after GC, the memory map of the heap after GC. The heap is used to store objects. It can be seen from the figure that as the GC progresses, the garbage collector reclaims all the objects, so the size of the heap gradually Increase.
The second part is Heap before GC, which is the usage rate of the heap before GC. It can be seen that as the program runs, the heap usage rate is getting higher and higher, and the memory occupied by the heap by the object is getting larger and larger.
The third part is GC Duration Time, which is the GC duration. The occurrence of a GC event has multiple stages, and different garbage collectors have different stages, which is not shown here. These phases (such as concurrent marking, concurrent cleaning, etc.) run concurrently with the program thread, and the program thread will not be suspended at this time. However, some stages (such as initial marking, clearing, etc.) will suspend the entire application, so this icon describes only the time spent in the suspended stage.
The fourth part represents the memory size of garbage objects collected by GC.
The fifth part shows Young Gen, the memory allocation of the young generation. Objects are all living and dying. The young generation stores the newly generated objects. Every time a GC is performed, a lot of garbage objects will be GC dropped, and the rest are objects associated with the right GC Root. These objects will gradually increase in age and reach A certain threshold will be promoted to the object of the old age. It can be seen that the graph represented by before GC gradually increases over time, that is, there are more and more objects in the young generation, and after a GC event occurs, the objects in the young generation will decrease, which is the after GC graph representation Trend of memory changes.
The sixth part is Old Gen, which represents the memory allocation in the old age. Careful readers will find, why the memory size of before GC is less than the memory allocation of after GC at the beginning? Here we must first know that the old age stores old objects, which means that objects that have not been GC dropped after many GCs will be promoted to objects of the old age. So this explains why after GC memory is larger than before GC memory, because every time after GC, there will be young generation objects promoted to old generation objects.
The seventh part is the heap memory allocation and promotion situation during each GC. The red line indicates how much memory (objects) in the young generation has been promoted to the old generation during each GC.
GC Statistics
GC Statistics displays some GC statistics. How much memory is reclaimed for each type of GC, how long it took in total, average time, and the individual statistics of each type of GC.
Object Stats (some statistics of the object)
GC Causes (GC Cause Information)
Memory Leak
Since there is no memory leak in the recorded program, there is no memory leak log information here. 5 out of 8 OOMs can be diagnosed here (Java heap memory overflow, GC overhead limit exceeded, request array size exceeds JVM limit, Permgen space, meta space).