Java virtual machine configuration parameters sometimes have a significant impact on the performance of SPL, this paper from the use of the sort function sortx explore how to optimize JVM configuration parameters to improve performance. Analysis of the process are not interested students can directly read the conclusion section.
1 memory constitution
| Old generation | The young generation |
| Eden | |
| S1 | |
| S2 |
As shown, memory in the Java virtual machine, it is often said of the heap, it is divided into the young generation and the old generation of the two parts. Target the young generation storage life cycle is very short, the old generation storage of long-lived objects. For example, after several garbage collection, a subject still alive, then the object will enter the old generation from the young generation.
The young generation is divided into three areas: Eden, Survivor 1, Survivor 2 (hereinafter referred to Eden, S1, S2). Eden storing new objects, S1, and S2 are used interchangeably, used to store survival of the subject when garbage.
2 recovery strategy
Java Virtual Machine garbage collection policy is very complicated, here we are only concerned about several situations that most affect performance.
Java's garbage collection divided into two types: Full GC and minor GC, the former is the recovery of the old generation, the general will be very slow, which is aimed at the younger generation of recycling, this soon. Our tuning goal is to avoid frequent Full GC. So what would trigger Full GC it? Above that, the new object will be stored in the Eden area, and when the Eden area is full when it will trigger minor GC, this time garbage objects Eden area will be cleared, and the surviving objects will be useful to S1 or S2 zone copy, thus completing the recovery process. In this process, if the S1 or S2 target area fit in Eden surviving, it will save the surviving objects to the old generation, old generation and if there is no space, it will trigger Full GC.
Brief is, when Survivor areas fit young generation surviving objects will result in the old generation growth, with the old generation is growing, Full GC is bound to be triggered.
Memory usage at 3 sortx
We know sortx function has parameters n, n is the number of buffers, each represents a number of records taken out from the cursor. So what is the most appropriate value n take it?
Obviously the value of n is not too large, otherwise it will cause memory overflow, can not be used.
Then again constantly trying to take a small point, after several attempts, you will find you can use, and will not overflow. But this time is not necessarily optimum values, if n is greater than the value of the memory occupied by Eden, and just the old generation almost occupied, then takes out the old generation data are sent, the next time until the fetch when triggered Full GC, and this is the most frequent trigger time-consuming.
So, from Java's distribution and recovery strategy point of view, the ideal situation is, n values memory occupied, slightly smaller than the size of Eden. This is because the characteristics of this type of operation sortx is "ready to use out, used to throw," there are few objects of permanent memory.
So how do you know the size of the Eden area and then estimate what n?
4 Memory Allocation
Starting configuration can be seen in the IDE, the -Xmx parameter specifies the size of the heap memory allocated to the java. For example -Xmx10g says 10G of memory allocated to Java. So how Java this 10G assigned to these zones it?
By default, the district ratio is about like this:
The young generation: the old generation = 3: 7
Eden: S1: S2 = 8: 1: 1
With the ratio, it is easy to work out the size of the district, the old generation accounted 7G, the young generation accounted for 3G, which accounted for Eden 2.4G, S1 and S2 each accounted for 0.3G. It is said that this is the default scale developers jdk statistics derived from that in most applications, accounting for one tenth of all the surviving target object. However, this ratio may not be suitable for all situations, at least when sortx is not appropriate.
5 Conclusion
The value of n Principle: When using sortx, without overflow, the value of n is not the better, but (depending on the size of Eden) estimate a suitable value which does not cause frequent Full GC.
Verify whether the value of n Suitable methods are as follows:
1 add parameters -XX: + PrintGC.
2 runs sortx.
Observation 3 console, if frequent information [Full GC (Allocation Failure) ......] the transfer of small n, try again.
If only a lot of 4 [GC (Allocation Failure) ......] information, the value of n is considered suitable.
If many 5 [GC (Allocation Failure) ......] message appears while occasionally [Full GC (Allocation Failure) ......] information, the value of n may be considered to be suitable.
6 to ensure that the temporary file can not be too small.
6 parameter adjustment
In general by adjusting n, to meet the basic performance of the sortx, if you want to further the pursuit of performance, we need to adjust the parameters. The default assignment of the young generation only a heap of 3/10, 7/10 and old generation memory that seems of little use when calculating the sortx this. If you want to adjust this ratio, in turn, allows sortx use a special boot configuration, you can use the parameters -XX: NewSize be adjusted.
For example, -XX: NewSize = 5g, to specify the size of the young generation is 5G.
Reminder, adjust the time, old generation can not leave too little space, accounting for 1/5 of the entire stack is appropriate. This is because Java's distribution strategy as well as many complex cases, such as the total space enough, but not continuous, still objects directly into the old generation. There are some similar situation, not repeat them.
Similarly, the proportion of Eden and S1, S2 can also affect performance, if you want to adjust this ratio can also use the parameter -XX: SurvivorRatio. For example -XX: SurvivorRatio = 1 represents Eden: S1: S2 = 1: 1: 1. -XX: SurvivorRatio = 8 represents Eden: S1: S2 = 8: 1: 1.
In general, the greater the Survivor areas, the smaller the probability that an object enters old age, so do sortx, tend configured to -XX: SurvivorRatio = 1.
7 Other
Configuration parameters are not consistent guidelines, needs to be adjusted according to the type of calculation, sometimes some good old generation of large (such as large dimension tables require permanent memory), sometimes bigger is better younger generations.