The JVM configures common parameters
Heap parameters
Collector parameters
As shown in the table above, there are mainly three kinds of serial, parallel and concurrent at present. For the application of large memory, serial performance is too low, so the two kinds of parallel and concurrent are mainly used. The policies for parallel and concurrent GC are specified by UseParallelGC and UseConcMarkSweepGC, as well as detailed configuration parameters to configure how the policies are executed. For example: XX: ParallelGCThreads, XX: CMSInitiatingOccupancyFraction, etc. In general, object collection in the Young region can only be selected in parallel (time consuming) and in the Old region in parallel (CPU consuming).
Common configurations in the project
Common combination
Common GC tuning strategies
GC tuning principles
Before tuning, we need to keep the following principles in mind:
Most Java applications do not require GC optimization on the server;
Most Java applications that cause GC problems are not because we set parameters incorrectly, but because of code problems;
Consider setting your machine’s JVM parameters to be optimal (best fit) before your application goes live.
Reduce the number of objects created;
Reduce the use of global variables and large objects;
GC optimization is a last resort;
In practice, there is much more to analyzing GC to optimize code than to optimize GC parameters.
GC tuning purposes
Minimize the number of objects migrated to older ages
Reduce GC execution time.
Strategy 1: Since the cost of Full GC is much higher than that of Minor GC, it is advisable to allocate objects to the new generation as much as possible. In the actual project, it is advisable to analyze whether the allocation of the space size of the new generation is reasonable according to GC logs, and adjust the size of the new generation appropriately through “-xMN” command. Minimize the possibility of new objects going straight to the old age.
Strategy 2: Large objects enter the old age, although in most cases it makes sense to assign objects to the new generation. However, this practice is debatable for large objects. If large objects are allocated in the new generation for the first time, there may be insufficient space in the old age when many small objects that are not old enough will be allocated, and the object structure of the new generation will be destroyed, which may lead to frequent full GC. Therefore, for large objects, you can set them to go straight to the old age (of course, short-lived large objects are a nightmare for garbage collection). – XX: PretenureSizeThreshold object size can be set directly into the old s.
-xx :MaxTenuringThreshold Sets the age of the object to enter the old age, reducing the memory usage of the old age, and reducing the frequency of full GC.
Strategy 4: Set a stable heap size with two parameters: -xms initial heap size and -xmx maximum heap size.
Strategy 5: Note: GC tuning is generally not required if the following metrics are met:
MinorGC takes less than 50ms to execute;
Minor GC is performed infrequently, about once every 10 seconds;
Full GC takes less than 1s to execute;
Full GC is performed infrequently, at least once every 10 minutes.
The JVM series:
In-depth analysis of JVM memory regions and memory overflow analysis
JVM to determine whether an object is dead and four garbage collection algorithms
The JVM configures common parameters and common GC tuning policies
7 JVM garbage collector features, Pros and cons, and usage scenarios!
The last
The follow-up will continue to update the performance optimization knowledge, write bad places also hope Daniel can give advice, we feel good can point a thumbs-up in the attention, will share more articles!