JVM (Java Virtual Machine) optimization overview and case studies

Document directory

• Young Generation
• Elder Generation
• Permanent generation

Heap memory setting principle JVM heap memory is divided into two parts: permanent space and heap space.

• Permanent (permanent generation) Stores Java class definition information and has little to do with the Java objects to be collected by the garbage collector.
• Heap = {old + new = {Eden, from, to}, old is the old generation, and new is the young generation ). The division of the old and young generations has a great impact on garbage collection.

Young Generation

All newly generated objects are first put in the young generation. The goal of the young generation is to quickly collect objects with short lifecycles as much as possible. Generally, the young generation has three zones, One Eden zone, and two consumer vor zones (from and ).

Most objects are generated in the Eden area. When the Eden area is full, the surviving objects will be copied to the same vor area (one of the two). When the other vor area is full, the surviving objects in this region will be copied to another region vor. When the other region vor region is full, the objects that are copied from the previous region vor region and are still alive at this time will be copied, it may be copied to the old generation.

The two vor regions are symmetric and irrelevant. Therefore, objects copied from the Eden area and replicated from the other vor areas may exist in the same region; objects copied to the old zone are only objects copied from the other region vor.In addition, at least one of the VOR zones in the region is empty due to the need for exchange.. In special cases, the VOR area can be configured as multiple (more than two) according to the program's needs, so that the existence time of the object in the young generation can be increased, reduce the possibility of being put into the old generation.

For the young generation, garbage collection is called young GC.

Elder Generation

Objects that are still alive after N (configurable) garbage collection in the young generation will be copied to the old generation. Therefore, it can be considered that objects with long lifecycles are stored in the old generation.

Garbage collection for older generations is full GC.

Permanent generation

It is used to store static data, such as Java class and method. Persistent generation has no significant effect on garbage collection. However, some applications may dynamically generate or call some classes, such as Hibernate cglib. In this case, you often need to set a large persistent storage space to store the dynamically added types during the running process.

Therefore, when a group of objects are generated,Memory application processAs follows:

1. JVM will try to initialize a memory area for the relevant Java objects in the Eden area of the young generation.
2. When the Eden area has sufficient space, the memory application is completed. Otherwise, execute the next step.
3. JVM tries to release all inactive objects (Young GC) in the Eden area ). After the Eden space is released, if the Eden space is still insufficient for new objects, the JVM tries to put active objects in some Eden areas into the same vor area.
4. The primary vor area is used as the intermediate exchange area of the Eden area and the old generation. When the old generation has enough space, objects that survive for a certain number of times in the VOR region will be moved to the old generation.
5. When the space of the old generation is insufficient, the JVM will perform full garbage collection (full GC) in the old generation ).
6. After full GC, if the primary VOR and the old generation still cannot store the objects copied from the Eden area, the JVM cannot apply for memory for the newly generated object in the Eden area, "Out of memory" appears ".

OOM ("out of memory") exceptions are generally caused by the following two reasons::

1. old Generation overflow, represented by: Java. lang. outofmemoryerror: javaheapspace this is the most common situation. The cause may be: the configured memory parameter xmx is too small or the program memory leaks and improper use. For example, string processing with a loop of tens of thousands of times, creating tens of millions of objects, and applying for hundreds of MB or even GB of memory in a piece of code. In other cases, although no memory overflow is reported, the system will not be able to process other requests without interrupting garbage collection. In this case, in addition to checking programs, printing heap memory, and other methods for troubleshooting, you can also use some memory analysis tools, such as mat. 2. persistent generation overflow, represented as: Java. lang. outofmemoryerror: permgenspace usually overflows because the persistent generation setting is too small and a large number of Java classes are dynamically loaded. The solution is to set the parameter-XX: maxpermsize is increased (generally M can meet the needs of most applications ). It is also an idea to load some Java classes in the container sharing area (for example, Tomcat share Lib), but the premise is that multiple applications are deployed in the container, these applications have a large number of shared class libraries. Parameter description

• -Xmx3550m: Set JVMMax heap memoryIt is 3550 M.
• -Xms3550m: Set JVMInitial heap memoryIt is 3550 M. This value can be set to the same as-xmx to avoid JVM re-allocating memory after each garbage collection.
• -Xss128k: Set the stack size of each thread. The size of each thread stack after JDK 256 is 1 MB, and that of each thread stack is kb. The memory size required by the Application Thread should be adjusted. Reduce this value to generate more threads in the same physical memory. However, the operating system still has a limit on the number of threads in a process. It cannot be generated infinitely. The experience is between 3000 and ~ About 5000. It should be noted that when this value is set to a large value (for example,> 2 MB), the system performance will be greatly reduced.
• -Xmn2g: SetYoung GenerationThe size is 2 GB. When the memory size of the entire heap is determined, increasing the size of the young generation will reduce the size of the old generation, and vice versa. This value is related to JVM garbage collection, which has a great impact on system performance. We recommend that you set this value to 3/8 of the total heap size.
• -XX: newsize = 1024 M: Set the initial value of the young generation to 1024 M.
• -XX: maxnewsize = 1024 M: set the maximum value of the young generation to 1024 M.
• -XX: permsize = 256 M: SetPermanent Initial ValueIt is 256 m.
• -XX: maxpermsize = 256 M: SetPermanent generation maximumIt is 256 m.
• -XX: newratio = 4: Set the ratio of the young generation (including one Eden and two vor regions) to the old generation. It indicates that the young generation is older than the old generation.
• -XX: Required vorratio = 4: SetRatio of Eden and vor in the young generation. The ratio of two vor zones (two vor zones of the same size by default in the young generation of JVM heap memory) to one Eden zone is, that is, one vor region accounts for 1/6 of the size of the entire young generation.
• -XX: maxtenuringthreshold = 7: indicates that if an object is moved seven times in the rescue space in the same vor region, it enters the old generation. If it is set to 0, the young generation object directly enters the old generation without going through the same vor area. For applications that require a large amount of resident memory, this can improve the efficiency. If this value is set to a greater value, the young generation object will be copied multiple times in the same vor area, which can increase the survival time of the object in the young generation, increase the probability of objects being reclaimed by garbage in the young generation and reduce the frequency of full GC. This can improve service stability to some extent.

Answer questions

-Xmn,-XX: newsize/-XX: maxnewsize,-XX: newratio three sets of parameters can affect the size of the young generation. In mixed use, what is the priority?
As follows:

1. High priority:-XX: newsize/-XX: maxnewsize
2. Medium Priority:-xmn (default equivalent-xmn =-XX: newsize =-XX: maxnewsize = ?)
3. Low priority:-XX: newratio

We recommend that you use the-xmn parameter because it is concise, equivalent to setting newsize/maxnewsize at a time, and the two are equal, suitable for the production environment. -Xmn works with-XMS/-xmx to complete the heap memory layout.

-The xmn parameter is supported in JDK 1.4. Garbage Collector Selection

JVM provides three options: Serial collector, parallel collector, and concurrent collector. The serial collector is only applicable to small data volumes. Therefore, the choice of the production environment is mainly the parallel collector and concurrent collector.

By default, jdk5.0 used the serial collector before. To use other collectors, you must add relevant parameters at startup. After jdk5.0, the JVM will perform intelligent judgment based on the current system configuration.

Serial collector

• -XX: + useserialgc: sets the serial collector.

Parallel collector (throughput first)

• -XX: + useparallelgc: Set to parallel collector. This configuration is only valid for young generations. That is, the young generation uses parallel collection, while the old generation uses serial collection.
• -XX: parallelgcthreads = 20: Number of threads configured for the parallel collector, that is, the number of threads simultaneously for garbage collection. We recommend that you set this value to be equal to the number of CPUs.
• -XX: + useparalleloldgc: configure the garbage collection mode for the old generation to parallel collection. Jdk6.0 began to support parallel collection of older generations.
• -XX: maxgcpausemillis = 100: sets the maximum time (in milliseconds) for garbage collection for each young generation ). If this time cannot be met, JVM will automatically adjust the size of the young generation to meet this time.
• -XX: + useadaptivesizepolicy: After this option is set, the parallel collector automatically adjusts the ratio of the Eden and vor of the young generation, to achieve the minimum response time or collection frequency specified by the target system. We recommend that you always enable this parameter when using the parallel collector.

Concurrent collector (Response Time First)

• -XX: + useconcmarksweepgc: CMS collection. You can set the age for concurrent collection. CMS collection is a new GC algorithm introduced in later versions of jdk1.4. It is mainly suitable for scenarios where the need for response time is greater than the need for throughput, and it can withstand the need for garbage collection threads and application threads to share CPU resources, there are many long-lifecycle objects in the application. The purpose of CMS collection is to minimize the pause time of the application and reduce the probability of full GC. It uses the garbage collection thread concurrent with the application thread to mark and clear the memory of the old generation.
• -XX: + useparnewgc: sets the young generation for concurrent collection. It can be used together with CMS collection. Jdk5.0 and later versions, JVM will be set based on the system configuration, so you do not need to set this parameter.
• -XX: cmsfullgcsbeforecompaction = 0. This parameter is set to compress and organize the memory space after 0 full GC operations, that is, the memory is compressed and sorted immediately after each full GC operation.
• -XX: + usecmscompactatfullcollection: Open the compression and sorting of the memory space, and run the command after full GC. Performance may be affected, but memory fragments can be eliminated.
• -XX: + cmsincrementalmode: Set to incremental collection mode. It is applicable to a single CPU.
• -XX: cmsinitiatingoccupancyfraction = 70: indicates that the CMS collection starts when the memory space of the old generation is used up to 70%, to ensure that the old generation has enough space to accept objects from the young generation, avoid full GC.

Other garbage collection Parameters

• -XX: + scavengebeforefullgc: the young generation GC is better than full GC.
• -XX:-disableexplicitgc: does not respond to system. GC () code.
• -XX: + usethreadpriorities: enables the local thread priority API. Even ifjava.lang.Thread.setPriority() It takes effect. If it is not enabled, it is invalid.
• -XX: softreflrupolicymspermb = 0: the soft reference object can survive for 0 milliseconds after the last access (the default JVM is 1000 milliseconds ).
• -XX: target1_vorratio = 90: 90% of region vor zones are allowed to be occupied (the default JVM value is 50% ). Improve the usage of the region vor area.

Auxiliary Information parameter settings

• -XX:-citime: the time consumed by printing the JIT compilation.
• -XX: errorfile =./hs_err_pid.log: Save the error log or data to the specified file.
• -XX: heapdumppath =./java_pid.hprof: Specifies the path for dump heap memory.
• -XX:-heapdumponoutofmemoryerror: dump the heap memory when the first memory overflow occurs.
• -XX: onerror = ";": run the custom command after a fatal error occurs.
• -XX: onoutofmemoryerror = ";": execute a custom command when the memory overflows for the first time.
• -XX:-printclasshistogram: press Ctrl + break to print the column information of class instances in the heap memory, which is the same as the JDK jmap-histo command.
• -XX:-printconcurrentlocks: press Ctrl + break to print information about the concurrent locks in the thread stack, which is the same as the JDK jstack-l command.
• -XX:-printcompilation: prints related information when a method is compiled.
• -XX:-printgc: prints related information each GC.
• -XX:-printgcdetails: prints detailed information each GC time.
• -XX:-printgctimestamps: prints the timestamp of each GC.
• -XX:-traceclassloading: trace class loading information.
• -XX:-traceclassloadingpreorder: tracks the loading information of all referenced classes.
• -XX:-traceclassresolution: trace constant pool.
• -XX:-traceclassunloading: Specifies the unload information of the trace class.

Parameter names

• Standard parameters (-), all JVM must support the functions of these parameters and are backward compatible; for example:
• -Client-- Set the JVM to use the client mode, which features Fast startup, but low performance and memory management efficiency during runtime. It is usually used for client applications or development and debugging; this mode is enabled by default when you directly run Java programs in a 32-bit environment.
• -Server-- Set the JVM to enable the server mode, which is characterized by slow startup speed, but high runtime performance and memory management efficiency, suitable for the production environment. This mode is enabled by default in a 64-bit JDK environment.
• Non-standard parameters (-x) are implemented by JVM by default, but not all JVM implementations are satisfied and backward compatibility is not guaranteed;
• Non-stable parameters (-xx). These parameters vary by JVM implementation and may not be supported in the future. Therefore, you must use them with caution;

JVM service parameter tuning Case Study of large-scale website servers

Dynamic Web applications with massive access

Server Configuration: 8 CPU, 8g MEM, JDK 1.6.x

Parameter scheme:

-Server-xmx3550m-xms3550m-xmn1256m-xss128k-XX: Export vorratio = 6-XX: maxpermsize = 256 m-XX: parallelgcthreads = 8-XX: bytes = 0-XX: + bytes

Optimization instructions:

• -Xmx is the same as-XMS to prevent JVM from re-applying for memory. -The size of xmx is approximately half the size of the system memory. That is, it makes full use of system resources and gives the system safe operation space.
• -Set the size of the young generation to 1256 MB for xmn1256m. This value has a great impact on system performance. Sun officially recommends that the young generation be 3/8 of the total heap size.
• -Set a smaller thread stack for xss128k to support creating more threads, massive access, and system performance improvement.
• -XX: Region vorratio = 6. Set the ratio of Eden to region vor in the young generation. The default value is 8. If the value is set to 6 based on experience, the ratio of two vor zones to One Eden zone is. One vor zone occupies 1/8 of the total number of young generations.
• -XX: parallelgcthreads = 8. Number of threads configured for the parallel collector, that is, 8 threads are collected together. This value is generally set to be equal to the number of CPUs.
• -XX: maxtenuringthreshold = 0: sets the maximum age of spam (the number of alive times in the young generation ). If it is set to 0, the young generation object directly enters the old generation without going through the VOR area. For applications with many older generations, the efficiency can be improved. If this value is set to a greater value, the young generation objects will be copied multiple times in the region vor, in this way, we can increase the survival time of objects in the young generation and the probability that objects will be recycled in the young generation. Based on the characteristics of a dynamic web application with massive access, its memory is either cached to reduce direct access to the database, or quickly recycled to support high concurrency and massive requests, therefore, it is of little significance to keep the memory object in the young generation for multiple times. You can directly enter the old generation. Based on the actual application effect, set this value to 0.
• -XX: + useconcmarksweepgc: set the age for concurrent collection. The purpose of CMS (concmarksweepgc) collection is to minimize the application pause time, reduce the probability of full GC, and use the garbage collection thread concurrent with the application thread to mark the removal of the old generation memory, this method is applicable when many long-lifecycle objects exist in an application.

Internal Integration build server case high performance data processing tools and applications

Server Configuration: 1 CPU, 4g mem, JDK 1.6.x

Parameter scheme:

-Server-XX: permsize = 196 m-XX: maxpermsize = 196 m-xmn320m-xms768m-xmx1024m

Optimization instructions:

• -XX: permsize = 196 m-XX: maxpermsize = 196 m based on the characteristics of integration construction, large-scale system compilation may require loading a large number of Java classes into the memory, therefore, it is highly efficient and necessary to allocate a large amount of persistent generation memory in advance.
• -Xmn320m follows the 3/8 principle of the entire heap size for the young generation.
• -Xms768m-xmx1024m: Set the heap memory size that the system can afford.

Run the application on a 64-bit server. Run the jmap-heap 11540 command to check the JVM heap memory:

Attaching to process ID 11540, please wait...
Debugger Attached successfully.
Server compiler detected.
JVM version is 20.12-B01

Using thread-local object allocation.
Parallel GC with 4 thread (s)

Heap Configuration:
Minheapfreeratio = 40
Maxheapfreeratio = 70
Maxheapsize = 1073741824 (1024.0 MB)
Newsize = 335544320 (320.0 MB)
Maxnewsize = 335544320 (320.0 MB)
Oldsize = 5439488 (5.1875 MB)
Newratio = 2
Required vorratio = 8
Permsize = 205520896 (196.0 MB)
Maxpermsize = 205520896 (196.0 MB)

Heap usage:
PS young generation
Eden space:
Capacity = 255852544 (244.0 MB)
Used = 101395504 (96.69828796386719 MB)
Free = 154457040 (147.3017120361328 MB)
39.63044588683081% used
From space:
Capacity = 34144256 (32.5625 MB)
Used = 33993968 (32.41917419433594 MB)
Free = 150288 (0.1433258056640625 MB)
99.55984397492803% used
To space:
Capacity = 39845888 (38.0 MB)
Used = 0 (0.0 MB)
Free = 39845888 (38.0 MB)
0.0% used
PS old generation
Capacity = 469762048 (448.0 MB)
Used = 44347696 (42.29325866699219 MB)
Free = 425414352 (405.7067413330078 MB)
9.440459523882184% used
PS perm generation
Capacity = 205520896 (196.0 MB)
Used = 85169496 (81.22396087646484 MB)
Free = 120351400 (114.77603912353516 MB)
41.440796365543285% used

The result is healthy.