Shulou(Shulou.com)06/03 Report--

How to improve performance by optimizing the configuration of JVM parameters? In view of this problem, today the editor summarizes this article on the use of sortx parameters, hoping to help more friends who want to solve this problem to find a more simple and easy way.

1 memory constitutes the old generation and the younger generation

EdenS1S2

As shown in the figure, the memory of the Java virtual machine, also known as the heap, is mainly divided into two parts: the younger generation and the older generation. The younger generation stores objects with a short life cycle, and the older generation stores objects that survive for a long time. For example, if an object is still alive after several garbage collections, the object will move from the younger generation to the older generation.

The younger generation is divided into three regions: Eden, Survivor 1, Survivor 2 (hereinafter referred to as Eden, S1, S2). Eden stores new objects, and S1 and S2 are used alternately to store objects that survive garbage collection.

2 recovery strategy

The garbage collection strategy for the Java virtual machine is complex, and here we are only concerned with the situations that affect performance the most.

Java garbage collection is divided into two types: Full GC and minor GC, the former is for the elderly, generally very slow, the latter is for the younger generation of recycling, which is very fast. The goal of our tuning is to avoid frequent Full GC. So what triggers Full GC? As mentioned above, the new objects will be stored in the Eden area, and when the Eden area is full, the minor GC will be triggered, and the junk objects in the Eden area will be removed, and the surviving useful objects will be copied to S1 or S2, thus completing a recycling process. In the process, if S1 or S2 cannot hold the surviving objects in Eden, the surviving objects will be saved to the older generation, and if the older generation is out of space, Full GC will be triggered.

In a nutshell, when the Survivor area is unable to hold the surviving objects of the younger generation, it will lead to the growth of the older generation, and as the older generation continues to grow, Full GC will inevitably be triggered.

Memory usage at 3 sortx

We know that the sortx function has a parameter, NLI n, which is the number of buffer entries, which represents the number of records fetched from the cursor each time. So what is the most appropriate value for n?

Obviously, n can not be too large, otherwise it will cause memory overflow and cannot be used at all.

Then keep trying to take a small point, after a few attempts, you will find that it can be used, will not overflow. However, it may not be the optimal value at this time. If the memory occupied by the n value is larger than Eden, and the older generation is almost occupied, the data retrieved each time will be sent to the older generation, and when the data is fetched next time, Full GC will be triggered. This frequent trigger is the most time-consuming.

Therefore, from the perspective of Java allocation and recycling strategy, ideally, the value of n takes up slightly less memory than the size of Eden. This is because operations such as sortx are characterized by "take it out and throw it away", and few objects reside in memory.

So how do you know the size of the Eden area and then estimate n?

4 memory allocation

As you can see in the startup configuration of IDE, the parameter-Xmx is used to specify the size of heap memory allocated to java. For example,-Xmx10g means that 10 gigabytes of memory is allocated to Java. So how does Java allocate these 10G to these zones?

By default, the proportion of each district is approximately as follows:

Younger generation: older generation = 3: 7

Eden: S1: S2 = 8: 1: 1

With the proportion, it is easy to calculate the size of each district, the older generation accounts for 7G, the younger generation accounts for 3G, of which Eden accounts for 2.4G, S1 and S2 each account for 0.3G. It is said that this default ratio is calculated by jdk developers, who believe that in most applications, surviving objects account for 10% of all objects. However, this ratio may not be suitable for all situations, at least not in sortx.

5 conclusion

N value principle: when using sortx, under the premise of no overflow, the value of n is not as large as possible, but to estimate an appropriate value (according to the Eden size), which does not cause frequent Full GC.

The methods to verify the appropriateness of n values are as follows:

1 add the parameter-XX:+PrintGC.

2 run sortx.

3 observation console, if frequent occurrence of [Full GC (Allocation Failure) …] Turn the message down to n and try again.

4 if there are only a lot of [GC (Allocation Failure).] Information, the value of n is considered appropriate.

5 if there are a lot of [GC (Allocation Failure).] Information at the same time, occasionally appear [Full GC (Allocation Failure) …] Information, the value of n can also be considered appropriate.

6 make sure that the temporary file is not too small.

6 adjust parameters

Generally speaking, by adjusting n, you can basically meet the performance of sortx, if you want to further pursue performance, you need to adjust parameters. The default allocation of the younger generation accounts for only 3x10 of the heap, while the memory sortx of the older generation of 7x10 seems to be of little use. If you want to adjust this ratio and allow sortx to use a dedicated startup configuration, you can use the parameter-XX:NewSize to adjust it.

For example,-XX:NewSize=5g, specifies that the size of the younger generation is 5G.

A hint, when adjusting, the older generation can not leave too little space, accounting for the entire heap of 1 big 5 is appropriate. This is because there are still many complexities in Java's allocation strategy, such as loading objects directly into the older generation when the total space is sufficient but not contiguous. There are some similar situations, so I won't repeat them.

Similarly, the ratio of Eden to S1 and S2 also affects performance, and you can use the parameter-XX:SurvivorRatio if you want to adjust this ratio. For example,-XX:SurvivorRatio=1 means Eden:S1:S2 = 1:1:1. -XX:SurvivorRatio=8 means Eden:S1:S2 = 8:1:1.

In general, the larger the Survivor area, the less likely the object is to enter the old age, so when doing sortx, it tends to be configured as-XX:SurvivorRatio=1.

7 other

There are no consistent guidelines for the configuration of parameters, which need to be adjusted according to the type of calculation. Sometimes it is better for the older generation (for example, large dimensional tables need to be resident in memory), and sometimes it is better for the younger generation.

After reading this article, have you learned to improve performance by optimizing the configuration of JVM parameters? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel. Thank you for reading.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.