A better-performing JVM parameter configuration and a brief introduction to the JVM

A better-performing Web server JVM parameter configuration:

-server//Server Mode-xmx2g//JVM the maximum allowable allocated heap memory, on demand-xms2g//JVM the initial allocated heap memory, generally and xmx configured to avoid the JVM reallocating memory after each GC. -xmn256m//Young generation memory size, entire JVM memory = young generation + old generation + persistent generation-xx:permsize=128m//persistent memory size-xss256k//Set stack size per thread-XX:+DISABLEEXPLICITGC// Ignoring the manual call to GC, the call to System.GC () becomes an air conditioner, without triggering GC-XX:+USECONCMARKSWEEPGC//concurrency Tag Cleanup (CMS) collector-xx:+cmsparallelremarkenabled// Reduce mark pauses-xx:+usecmscompactatfullcollection//size of compressed-xx:largepagesizeinbytes=128m//memory pages for older generations when full GC-xx:+ Usefastaccessormethods//Fast optimization of the original type-xx:+usecmsinitiatingoccupancyonly//Start the CMS collection-xx using the manual definition initialization definition: CMSINITIATINGOCCUPANCYFRACTION=70//Use CMS as garbage collection after 70% start CMS collect

Description

The ratio of-xmn to-xmx is about 1:9, and if the new generation of memory is set too much, it can lead to a longer GC time.

A good web system should be every time the HTTP request request memory can be recovered in the young GC, the full GC never happens, of course, this is the ideal situation

The value of XMN should be set to be as small as possible (enough for HTTP concurrent requests)

Web server and Game server configuration ideas are not the same, the most important difference is the game server xmn that the younger generation set relatively large, and xmx about 1:3 of the relationship, because the game server is generally a long connection, in maintaining a certain amount of concurrency after the need for a large number of young generation heap memory, If the size is set, it will often cause young GC

• Introduction to the JVM

It can be seen that the JVM heap memory is categorized, and the JVM memory is divided into separate sections.
Broadly speaking, the JVM heap memory is divided into two parts-the young Generation and the older generation (old Generation).

• Young generation

The young generation is where all new objects are generated. Garbage collection is triggered when the memory space of the young generation is exhausted. This garbage collection is called the minor GC. The young generation is divided into 3 parts of the--enden district and two survivor districts.


highlights of the young generation space:
Most new objects are located in the Eden area.
When the Eden area is filled with objects, the minor GC is executed. and transfer all surviving objects to one of the survivor areas.
The Minor GC also checks for surviving objects and transfers them to another survivor area. In this way, there will always be an empty survivor area for a period of time.
After several GC cycles, the surviving objects are transferred to the old generation memory space. This is usually done by setting an age threshold before the younger generation is eligible to ascend to the old age.

• Old generation

Older generations of memory contain long-lived objects and objects that survived multiple minor GC. Garbage collection is usually done in the old years when memory is full. Garbage collection in the old age is called Major GC. Major GC will take more time.


Stop the World event
All garbage collection is "Stop the World" event, because all application threads will stop until the operation is complete (so called "Stop the World").

Because the objects in the young generation are temporary (short-lived) objects, executing the minor GC is very fast, so the app will not be affected by ("Stop the World").

Because the major GC checks for all surviving objects, it takes longer. Major GC should be minimized. Because the major GC makes your app unresponsive during garbage collection, you'll see a time-out error if you have an application that needs a quick response that happens multiple times major GC.

Garbage collection time depends on the garbage collection policy. This is why it is necessary to monitor garbage collection and to tune garbage collection. This avoids time-out errors for applications that require fast response.

• Permanent generation

The permanent generation or "Perm Gen" contains the application metadata required by the JVM, which describes the classes and methods used in the application. Note that the permanent generation is not part of the Java heap memory.
Permanently stores the classes used by the JVM runtime. The permanent generation also contains classes and methods for the Java SE library. A permanent object is garbage collected at full GC.


Method Area
A method area is part of a permanent generation space and is used to store type information (run constant and static variables) and method code and constructor code.


Memory Pool
If the JVM implements support, the JVM memory management creates an object pool for the immutable object to create the memory pool. A string pool is a good example of a memory pool type. The memory pool can belong to a heap or a permanent generation, depending on the implementation of the JVM memory management.


run a constant-rate pool
The run-time constant pool is the runtime representative of each class of const pool. It contains the run-time and static methods of the class. Running a constant pool is part of the method area.


Java Stack Memory
Java stack memory is used to run threads. They contain temporary data from the method and specific data referenced by other objects in the heap.

Java garbage Collection
Java garbage collection finds useless objects, removes them from memory, and frees up memory for objects created later. One of the biggest advantages of the Java programming language is automatic garbage collection, unlike other programming languages where you need to manually allocate and free memory, such as the C language.

The garbage collector is a background run program. It manages all objects in memory and finds objects that are not referenced. All of these unreferenced objects are deleted, their space is reclaimed and assigned to other objects.

A basic garbage collection process involves three steps:
Tags: This is the first step. In this step, the garbage collector will find out what objects are being used and which objects are not in use.
Normal purge: The garbage collector clears the objects that are not in use, and reclaims their space for allocation to other objects.
Compression cleanup: To improve performance, compression cleanup moves all surviving objects together after removing useless objects. This can improve the efficiency of assigning new objects.


There are two problems with simple tagging and purging methods:
Efficiency is low. Because most new objects will become "useless objects."
Objects that pass through multiple garbage collection cycles are likely to survive in later cycles.
The problem with the simple cleanup method above is that Java garbage collection is recycled, and there are two regions in the heap memory for young generation and older generations.

• Java garbage Collection types

There are five types of garbage collection that you can use in your app.

Only the JVM switch is required to enable the garbage collection policy in our application.

Serial GC (-XX:+USESERIALGC): Serial GC uses simple tagging, purging, and compression methods for garbage collection of young and old generations, that is, minor GC and major GC. The Serial GC is useful in client mode, such as in simple standalone applications and lower CPU configurations. This pattern works well for applications that occupy less memory.
Parallel GC (-XX:+USEPARALLELGC): In addition to generating n threads for the generation of garbage collection, Parallel GC and serial GC are almost the same. Here n is the number of cores of the system CPU. We can use the-xx:parallelgcthreads=n this JVM option to control the number of threads. The parallel garbage collector is also called the throughput collector. Because it uses multiple CPUs to speed up garbage collection performance. The Parallel GC uses a single thread for old generation garbage collection.
Parallel old GC (-XX:+USEPARALLELOLDGC): Same as parallel GC. In contrast, the Parallel old GC uses multi-threaded collection when it comes to young generation garbage collection and older generation garbage collections.
Concurrent Markup Cleanup (CMS) collector (-XX:+USECONCMARKSWEEPGC): The CMS collector is also known as a short pause concurrency collector. It is a garbage collection for old generations. The CMS collector collects garbage from multiple threads concurrently, minimizing the pauses caused by garbage collection. The CMS collector uses the same algorithm as the parallel collector for garbage collection for younger generations. This garbage collector is suitable for applications that cannot tolerate long pauses requiring rapid response. You can use the-xx:parallelcmsthreads=n JVM option to limit the number of threads for the CMS collector.
G1 garbage collector (-XX:+USEG1GC) G1 (garbage first): The garbage collector is a feature that can be used after Java 7, and its long-term goal is to replace the CMS collector. The G1 collector is a parallel, concurrent, and incremental compressed garbage collector that briefly pauses. The G1 collector does not operate in the same way as other collectors, and does not differentiate between young and old generation spaces. It divides the heap space into areas of equal size. When garbage collection is done, it takes precedence over areas where there are fewer surviving objects, so it is called "garbage first".

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

A better-performing JVM parameter configuration and a brief introduction to the JVM