Written in the previous words
Recently in the work always encountered the service of the QPS in the time of the test is less than the case. So the performance optimization journey began, and the process was very tortuous. In the beginning, it was thought that the business logic of the service was more, and most of the time was spent optimizing business logic, reducing calls to interfaces such as other services and databases, and using caching to improve performance. The above work is to improve the performance, but for a skilled migrant workers, the characteristics of the language has been fully confident, it is difficult to optimize the one or two code to obtain a qualitative improvement. Since the current use of micro-service development, the parameters of the JVM is set by itself, just want to optimize in this area.
By analyzing the number and time of GC (using the Jstat tool) during the pressure measurement process, the number of GC times in the stress test has reached the critical factor that affects the performance of the boost. So we started to reduce the number of GC.
The purpose of this optimization is two :
1 , the number of objects to be transferred to the old age is reduced to a minimum;
2 , reduce Full GC time of execution;
From the Internet to see some of the JVM tuning methods, one of the people sharing the program tuning method feel with their own situation special service, special here to share with you:
“
It's all for this one step, tuning, before tuning, we need to remember the following principles:
1 , the majority of Java apps do not need to be on the server GC optimization;
2 , most causes GC Problem of Java application, is not because of our parameter setting error, but the code problem;
3 before the application goes live, consider the machine's JVM The parameter is set to the optimal (most suitable);
4 , reduce the number of objects created;
5 , reducing the use of global variables and large objects;
6 , GC optimization is the last resort to use;
7 , in practical use, the analysis GC condition optimized code than optimization GC The parameters are much more;
In order to achieve the above purpose, generally, the things you need to do are:
1 , reducing the use of global variables and large objects;
2 , adjust the size of the Cenozoic to the most appropriate;
3 , set the size of the old age as the most appropriate;
4 , choose the right GC collecting device;
”
JVM Stack composition and partitioning
With the idea above, let's look at the structure of the JVM stack below. The JVM stack consists of three parts: The new generation, the old age, and the permanent generation. The image describes the division of each district:
We can see the structure of the heap memory space.
1. JVM heap memory consists of three regions: the Cenozoic (Yong Generation), the old generation (tenured Generation) and the permanent Band (Perm Generation);
2. The Cenozoic consists of three parts: one Eden area and two Survivor District;
3. Two survivor area A called from, a called to, literally can see the role of two;
4. The default scale for Eden and Survivor is 8:1. In general, newly created objects are assigned to the Eden area (some large object special handling) that, after the first minor GC, will be moved to the survivor area if it survives. Object in the Survivor area each time minor GC, age will increase by 1 years, when its age to a certain extent, it will be moved to the old generation.
The process of moving objects during GC
At the beginning of the GC, the object will only exist in the Eden area and the survivor area named "from", and the Survivor area "to" is empty. All surviving objects in the Gc,eden area are then copied to the "to", and in the "from" area, the surviving objects are determined according to their age values. Objects that reach a certain age (age threshold, which can be set by-xx:maxtenuringthreshold) are moved to older generations, and objects that do not reach the threshold are copied to the "to" area. After this GC, the Eden Zone and the from zone have been emptied. At this time, "from" and "to" will exchange their role, that is, the new "to" is the previous GC "from", The new "from" is the previous GC "to". In any case, the survivor area named to is guaranteed to be empty. The Minor GC repeats this process until the "to" area is filled and the "to" area is filled, and all objects are moved into the old generation.
JVM run-time key parameter settings
Parameter name |
Description |
Tip |
-xms |
Minimum value of the heap |
32-bit system, generally limited to 1.5g~2g;64 for OS-to-memory unlimited |
-xmx |
Maximum heap space |
32-bit system, generally limited to 1.5g~2g;64 for OS-to-memory unlimited |
-xmn |
Young Generation Size |
The entire heap size = younger generation size + old generation size + persistent generation size. The permanent average fixed size is 64m, so increasing the younger generation will reduce the size of older generations. This value has a large impact on system performance, and Sun's official recommendation is 3/8 for the entire heap. |
-xss |
Set the stack size for each thread |
After JDK5.0, each thread has a stack size of 1M, before each thread has a stack size of 256K. The size of the memory required for the more applied threads to be adjusted. In the same physical memory, reducing this value can generate more threads. However, the operating system of the number of threads within a process is still limited, can not be generated indefinitely, the empirical value of 3000~5000 around. |
-xms |
Minimum value of the heap |
32-bit system, generally limited to 1.5g~2g;64 for OS-to-memory unlimited |
JVM parameters for the young generation
1)-xx:newsize and-xx:maxnewsize
For setting the size of the young generation, it is recommended to set the size of the entire heap to 1/3 or 1/4, and two values to be set as large.
2)-xx:survivorratio
This value is also important for setting the ratio of Eden to one of the survivor. Sets the ratio of the Eden to the survivor area in the younger generation. Set to 4, the ratio of two survivor to one Eden area is 2:4, and a survivor area represents 1/6 of the entire young generation.
3)-xx:newratio=4
Set the ratio of the younger generation (including Eden and two survivor) to the older generation (except for the persistent generation). Set to 4, the ratio of the young generation to the old generation is 1:4, and the younger generation takes up 1/5 of the entire stack.
4)-xx:+printtenuringdistribution
This parameter is used to display the size of objects of each age group in the survivor area each time the GC is minor.
5)-xx:maxpermsize=16m
It is recommended to set the durable generation size to 16m.
6)-xx:initialtenuringthreshol and-xx:maxtenuringthreshold
Used to set the minimum and maximum age of an object for promotion to the old age, with each object having persisted once minor GC, the age increases by 1.
-xx:maxtenuringthreshold=0. Set the maximum age for garbage. If set to 0, then the young generation object does not go through the survivor area, directly into the old generation. For older generations of more applications, can improve efficiency. If this value is set to a larger value, the younger generation objects are duplicated multiple times in the Survivor area, which increases the survival time of the object's younger generations, increasing the introduction of being recycled in the younger generation.
Throughput collector
1)-XX:+USESERIALGC
Activating a serial garbage collector such as single-threaded throughput-oriented garbage collector recommended for a single CPU-only JVM
2)-XX:+USEPARALLELGC
Performing young generation garbage collection in parallel using multithreading
3)-xx:+useparalleloldg
In addition to activating the young generation of parallel garbage collection, it also activates the old generation of parallel garbage collection
4)-xx:parallelgcthreads
-xx:parallelgcthreads=<value> specifying the number of threads for parallel garbage collection
5)-xx:-useadaptivesizepolicy
The garbage collector can apply dynamic changes in heap size to different heap areas like GC settings, as long as there is evidence that these changes will improve GC performance
6)-xx:gctimeratio
-xx:gctimeratio=<value> Specify the target value to be reached for JVM throughput
Specifies the target application thread execution time and total program execution time to reach the target ratio of n/(n+1)
By-xx:gctimeratio=9 we require that the application thread be active at least 9/10 of the entire execution time (therefore, the GC thread occupies the remaining 1/10)
The default value for-xx:gctimeratio is 99, which means that the application thread should run at least 99% of the total execution time
7)-xx:maxgcpausemillis
-xx:gctimeratio=<value> tells JVM maximum pause time target value [MS]
CMS collector
1)-XX:+USECONCMARKSWEEPGC
Activating the CMS collector JVM by default uses a parallel processor
2)-XX:USEPARNEWGC
Activating a young generation using a CMS collector to perform garbage collection in parallel using multithreading
Attention:
The latest version of the JVM, when-XX:+USECONCMARKSWEEPGC is used,-XX:USEPARNEWGC is turned on automatically.
Therefore, if the young generation's parallel GC does not want to be turned on, it can be switched off by setting-XX:-USEPARNEWGC.
3)-xx:+cmsconcurrentmtenabled
Concurrent CMS stage is enabled by default in multithreaded execution
4)-xx:concgcthreads
-xx:concgcthreads=<value> defines the number of threads running in a concurrent CMS
If the flag is not set, the JVM calculates the default number of parallel CMS threads based on the value of the-xx:parallelgcthreads parameter in the parallel collector. The formula is Concgcthreads = (parallelgcthreads + 3)/4. Therefore, for the CMS collector
The-XX:PARALLELGCTHREADS flag affects not only the "Stop-the-world" garbage collection phase, but also the concurrency phase.
5)-xx:cmsinitiatingoccupancyfraction
-xx:cmsinitiatingoccupancyfraction=, which represents the usage of heap space in the old age. For example, value=75 means that the first CMS garbage collection will be triggered when the old age is occupied by 75%. Usually the default value of Cmsinitiatingoccupancyfraction is 68 (which is determined by the experience of a long time ago).
6)-xx:+usecmsinitiatingoccupancyonly
Command JVM does not start the CMS garbage collection cycle based on data collected at run time
The JVM collects every CMS through cmsinitiatingoccupancyfraction values, not just the first time
7)-xx:+cmsclassunloadingenabled
The CMS does not garbage recycle the permanent generation by default if you want to have the permanent generation garbage collected you can set this flag
Note that even if this flag is not set, a garbage collection will be attempted once the permanent generation is exhausted, but the collection will not be parallel and the full GC again.
8)-xx:+cmsincrementalmode
To open the incremental mode of the CMS collector
PS: Incremental mode often pauses the CMS process to make full concessions to the application
9)-xx:+explicitgcinvokesconcurrent and-xx:+explicitgcinvokesconcurrentandunloadsclasses
1.-xx:+explicitgcinvokesconcurrent
Command JVM whenever the system GC is invoked, execute the CMS GC instead of the full GC
2.-xx:+explicitgcinvokesconcurrentandunloadsclasses
Ensure that when a system GC is called, the permanent generation is also included in the CMS garbage collection. Therefore, by using these flags, we can prevent the unexpected "Stop-the-world" system GC from appearing.
)-XX:+DISABLEEXPLICITGC
This flag tells the JVM to completely ignore the system's GC calls (regardless of the type of collector used)
Summarize
The JVM parameter is dead, and the scene for your service is alive. In the process of tuning, we need to constantly adjust the parameters, test and re-adjust the iterative way to the optimal performance according to your business needs.
It is recommended that you use the Jstat Java Automatic Detection GC tool, which is helpful for viewing GC information of the system.
Resources
A list of the official JVM parameters:
Http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
51544977
JVM Tuning Summary