Although it has not been optimized. However, I feel that this needs to be supported based on actual business needs and business capabilities to optimize it.
JVM optimization can be discussed for hours. Here I will give you some simple opinions without going into systematic details.
First: Your problem is that full gc is frequent. Check whether the total memory and old generation settings are too small. It mainly depends on the parameters -Xmx and -Xmn. If it is too small, gc will inevitably occur frequently.
Second: Add the following parameters -verbose.gc -XX:+PrintGC -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime -XX:+PrintTenuringDistribution - Xloggc:/data/log/xxx/xxx-gc.log -XX:+PrintGCDetails Check how much space is left in the old generation after each gc. Generally speaking, the space in the old generation is set to 2-2.5 times the memory after gc is a more reasonable value. At the same time, you can see through this log whether a large number of objects enter the old generation without sufficient gc in the new generation. If objects that can be recycled through the new generation enter the old generation, full gc will inevitably occur frequently
Third: Code reason dump memory jmap -dump:live,format=b,file=xx.bin [pid] Then look at it through the MAT (http://www.eclipse.org/mat/) tool Which large piece of memory has not been released?
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Although it has not been optimized. However, I feel that this needs to be supported based on actual business needs and business capabilities to optimize it.
Look at the heap size and qps of the Java application, but initially looking at the full gc every 20 minutes, it seems not normal
JVM optimization can be discussed for hours. Here I will give you some simple opinions without going into systematic details.
First: Your problem is that full gc is frequent. Check whether the total memory and old generation settings are too small.
It mainly depends on the parameters -Xmx and -Xmn. If it is too small, gc will inevitably occur frequently.
Second: Add the following parameters
-verbose.gc -XX:+PrintGC -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime -XX:+PrintTenuringDistribution - Xloggc:/data/log/xxx/xxx-gc.log -XX:+PrintGCDetails
Check how much space is left in the old generation after each gc. Generally speaking, the space in the old generation is set to 2-2.5 times the memory after gc is a more reasonable value.
At the same time, you can see through this log whether a large number of objects enter the old generation without sufficient gc in the new generation. If objects that can be recycled through the new generation enter the old generation, full gc will inevitably occur frequently
Third: Code reason dump memory
jmap -dump:live,format=b,file=xx.bin [pid]
Then look at it through the MAT (http://www.eclipse.org/mat/) tool Which large piece of memory has not been released?