This article briefly talks about how to tune the JVM.
The success of the Java language itself, in addition to the right time and place, the JVM is indispensable.
It is no exaggeration to say that JVM is one of the most successful cases of modern software engineering. It has a large scale and extremely complex code, but it runs extremely stable and reliable. Therefore, many manufacturers' core business systems want to write in Java and run on the JVM with confidence.
Because JVM comes with GC and there are countless parameters that can be fine-tuned, JVM tuning has now been regarded as a compulsory knowledge point for Java interviews.
I have written Java programs for so many years. Unfortunately, I have only used two parameters so far: XMS and XMX, and can correctly write the following startup script:
java -Xms1g -Xmx2g -jar abc.jar
-serveryou count it, there will be three parameters in total. It is estimated that the probability of passing the interview is not high.
I admit that I know almost nothing about JVM tuning. The reason is that I have not encountered performance problems that must be solved by JVM tuning.
I found two types of people who like to study JVM tuning:
In most cases, if the program has performance problems, such as the TPS can’t go up and the memory is bursting, it’s best to calm down by yourself and monitor the logs and performance data of your program first. If you don’t have these two, just take a bite. Surely there is a problem with the JVM, the problem is probably not the JVM, but the attitude.
This is not to say that the JVM will not have problems, or that the JVM is definitely free of bugs, but that in the software field, whether bugs can be discovered and fixed as much as possible depends largely on whether there are enough people. In this world, are there many people who use JVM or use their own programs? Obviously, the possibility of a JVM bug that can be found by someone is very low, especially the company's online JVM will not pursue the latest version.
So what is the correct way to tune the JVM? I personally recommend four steps:
Keep a specific logs;
Working on for monitoring the performance of the program;
Modify the program based on the logs and performance monitoring data;
Use professional tools to perform stress testing through different JVM parameters and obtain the best configuration.
According to my personal experience, after taking the first three steps, you can deliver with high quality codes, the fourth step is to be done if time is enough.
Over the years, I have encountered two problems caused by JVM parameters:
Once it was a very large Java program of a certain company that caused PermGen OutOfMemoryError. It was the JDK 1.6 platform. The reason was simple. The number of Java classes written was too many, which broke the default 128M PermGen. The solution is also very simple, change to a larger 512M (the parameter name has been forgotten, because the new version of the JVM does not have PermGen restrictions). But the fundamental problem is not the JVM, but the code is too junk, caused by the excessive number of Java classes.
The other time was a crash due to insufficient memory due to the ultra-high TPS, but in fact the memory was 32G very large, and 30G allocated to the JVM was impossible to run out. The reality is that EC2 has been killed directly, even the logs can't be seen. If you manually lower the TPS (each sleep 1ms), you can start successfully with a certain probability. After consulting AWS technical support, I found that it was Kafka that used a lot of off-heap memory in order to increase the speed, and it broke under high TPS. The solution is also very simple, limit the JVM memory to half of the system memory, leaving enough memory for the operating system. The fundamental problem this time is that the code performance is too high but XMS and XMX are set incorrectly.
Therefore, in most cases, there is no need to tune the JVM, because that is the last step of optimization. Even if you really need it, but all in all you don’t have to care about the performance of the JVM before solving the performance problems of your own programs.