Shulou(Shulou.com)05/31 Report--

This article mainly shows you the "JVM commonly used memory parameter configuration", the content is easy to understand, clear, hope to help you solve the doubt, the following let the editor lead you to study and learn "what are the common memory parameter configuration of JVM" this article.

-Xms

The initial heap value applied for when JVM starts, defaults to 1x64 but less than 1G of the operating system's physical memory. By default, when the free heap memory is greater than 70%, JVM reduces the size of heap to the size specified by-Xms, which can be specified by-XX:MaxHeapFreeRation=. For Server JVM, it is best to set-Xms and-Xmx to the same value to avoid JVM redistributing memory after each garbage collection. JVM, the development test machine, can keep the default value. (for example:-Xms4g)

-Xmx

The maximum heap value that can be applied for by JVM. The default value is 1x4 but less than 1G of physical memory. By default, when the free heap memory is less than 40%, JVM will increase the Heap to the size specified by-Xmx, which can be specified by-XX:MinHeapFreeRation=. The best setting should depend on the physical memory size and other memory overhead in the computer. (for example:-Xmx4g)

-Xmn

Java Heap Young area size. Overall heap size = younger generation size + older generation size + persistent generation size (compared to HotSpot type virtual machines). The permanent generation usually has a fixed size of 64m, so increasing the size of the younger generation will reduce the size of the old generation. This value has a great impact on system performance, and Sun officially recommends that it be configured as 3Universe 8 of the entire heap. (for example:-Xmn2g)

The newly created objects of the program are all allocated memory from the younger generation, which is composed of Eden Space and two pieces of SurvivorSpace of the same size (usually called S0 and S1 or From and To). The size of the younger generation can be specified by the-Xmn parameter, and the size of Eden Space and SurvivorSpace can also be adjusted by-XX:SurvivorRation.

The old era is used to store objects that are still alive after many times of the new generation of GC, such as cache objects. New objects may also directly enter the old age. There are two main situations: 1. Large objects can be allocated directly in the old era by setting the startup parameter-XX:PretenureSizeThreshold=1024 (unit is bytes, default is 0) to represent how old it is. 2. Large array objects, and no external objects are referenced in the array. The memory occupied by the old age is the corresponding value of-Xmx minus the corresponding value of-Xmn. If there is no memory in the heap to complete the instance allocation, and the heap can no longer be expanded, an OutOfMemoryError exception will be thrown.

-Xss

Java the Stack size of each thread. The stack size of each thread after JDK5.0 is 1m, and the stack size of each thread before is 256K. Adjust according to the amount of memory required by the applied thread. Decreasing this value generates more threads under the same physical memory. However, the operating system still has a limit on the number of threads in a process, which cannot be generated indefinitely, and the experience value is about 3000 to 5000. (for example:-Xss1024K)

-XX:PermSize

The initial memory size of the persistent generation (method area). (for example:-XX:PermSize=64m)

-XX:MaxPermSize

The maximum memory size of the persistent generation (method area). (for example:-XX:MaxPermSize=512m)

-XX:+UseSerialGC

Serial (SerialGC) is the default GC mode of jvm, which is generally suitable for small applications and single processors. The algorithm is relatively simple and GC efficiency is high, but it may bring standstill to applications.

-XX:+UseParallelGC

ParallelGC refers to the parallel execution of GC by multiple threads, which is generally suitable for multiprocessor systems and can improve the efficiency of GC, but the algorithm is complex and the system consumes a lot. (with:-XX:ParallelGCThreads=8, the number of threads in the parallel collector, which is preferably configured equal to the number of processors)

-XX:+UseParNewGC

Set the younger generation to collect in parallel. Above JKD5.0, JVM will be set according to the system configuration, so there is no need to set this value.

-XX:+UseParallelOldGC

Set the parameter options that appear in JKD6.0 for parallel collection in the old age.

-XX:+UseConcMarkSweepGC

ConcMarkSweepGC means that when GC runs, it has almost no effect on the running of the application (it also causes a pause, but very little), and the threads of both GC and app are executing concurrently, so as to minimize the impact on the running of app.

-XX:+UseCMSCompactAtFullCollection

At the time of Full GC, compress and sort out the old age. Because CMS does not move memory, it is very easy to produce memory fragmentation. Therefore, by adding this parameter, you can compress and defragment the memory after FullGC. Of course, this operation also has some disadvantages, that is, it will increase CPU overhead and GC time, so you can use the parameter-XX:CMSFullGCsBeforeCompaction=3 to control how many times FullGC is defragmented later.

-XX:+CMSInitiatingOccupancyFraction=80

On behalf of the old era, after the use of space reached 80%, Full GC will be carried out. The CMS collector works with applications during garbage collection, so you can't wait until the old days are almost completely filled, which affects the space usage of concurrent application threads and triggers unnecessary Full GC again.

-XX:+MaxTenuringThreshold=10

The maximum age of garbage represents that the object enters the old age after 10 copies in the Survivor area. If set to 0, the younger generation will enter the old age without going through the Survivor area.

JVM startup parameters are divided into three categories:

1. Standard parameters (-). All JVM implementations must implement the functions of these parameters and are backward compatible. For example:-verbose:class (output information about jvm loading classes, which can be diagnosed when jvm reports that classes can not be found or class conflicts);-verbose:gc (output information about each GC);-verbose:jni (output information about native method calls, which is generally used to diagnose jni call error messages).

2. Non-standard parameters (- X). The default jvm implements the functions of these parameters, but it does not guarantee that all jvm implementations are met, and backward compatibility is not guaranteed. For example:-Xms512m;-Xmx512m;-Xmn200m;-Xss128k;-Xloggc:file (similar to-verbose:gc function, except that the relevant information about each GC event is recorded in a file, preferably locally, to avoid potential network problems. If it appears on the command line at the same time as the verbose command, then-Xloggc shall prevail.

3. Non-Stable parameter (- XX), which varies from jvm implementation to jvm implementation, which may be cancelled at any time in the future and needs to be used with caution. For example:-XX:PermSize=64m;-XX:MaxPermSize=512m.

No matter in the process of YGC or Full GC,GC, there will be interruptions in the process of program operation. Choosing different GC strategies correctly and adjusting the parameters of JVM and GC can greatly reduce the problems of program interruption caused by GC work, and then appropriately improve the work efficiency of Java programs. But adjust GC is an extremely complex process, because each program has different characteristics, such as: web and GUI procedures are very different (Web can be appropriate pause, but GUI pause is unacceptable to customers), and because the configuration running on each machine is different (the number of main cup, memory is different), so the type of GC used will be different (see GC type and how to choose). This paper will focus on introducing some important parameters of JVM and GC to improve the performance of the system. JVM memory composition and GC related content can be found in the previous article: JVM memory composition GC Strategy & memory request. For an example of the meaning of JVM parameter, please see the example analysis as follows:

Parameters related to the parallel collector:

Parameters related to CMS:

Auxiliary information:

3.1 GC performance considerations

There are two main indicators for the performance of GC: throughput throughput (the ratio of working time to total time other than gc) and pausing pause (the external display of app is unresponsive when gc occurs).

1. Total Heap, by default, vm increases / decreases the heap size to maintain the proportion of free space in the entire vm, which is specified by MinHeapFreeRatio and MaxHeapFreeRatio. In general, the app on the server side has the following rule: assign as many memory; as possible to vm and set Xms and Xmx to the same value. If the virtual machine is set up with a small amount of memory and many objects need to be initialized, the virtual machine must increase the memory repeatedly. As the number of processor cores increases, so does the memory.

2. The Young Generation, another factor that affects the fluency of app is the size of young generation. The larger the younggeneration, the less minor collection; but in the case of fixed heap size, a larger younggeneration means a smaller tenured generation, which means more major collection (major collection throws a minor collection). NewRatio reflects the size ratio of young to tenured generation. NewSize and MaxNewSize reflect the lower and upper limits of the young generation size, and setting these two values to the same value fixed the size of the young generation (the same as Xms and Xmx). SurvivorRatio can also optimize the size of the survivor if desired, but this does not have a significant impact on performance. SurvivorRatio is the ratio of eden to survior size. Generally speaking, the app on the server side has the following rules: first determine the maximum heap size that can be assigned to the vm, and then set the optimal size of the young generation; if the heap size is fixed, increasing the size of the young generation means reducing the tenured generation size. Make the tenured generation large enough at any time to accommodate all the live's data (leaving 10% Murray 20% free).

3.2 experience & rules

1. Young generation size selection: applications with priority response time: make it as large as possible until it is close to the minimum response time limit of the system (according to the actual situation). In this case, the frequency of younger generation collection is also the smallest. At the same time, reduce the number of objects that reach the older generation; throughput priority applications: set as large as possible, possibly to the extent of Gbit. Because there is no requirement for response time, garbage collection can be carried out in parallel, which is generally suitable for applications above 8CPU; avoid setting too small. When the new generation is set too small, it will lead to more frequent 1.YGC times. It may cause the YGC object to enter the old generation directly, and if the old generation is full, it will trigger FGC.

2. Older generation size selection: applications with priority response time: older generations use concurrent collectors, so their size needs to be set carefully, and some parameters such as concurrent session rate and session duration should be considered. If the heap setting is small, it can cause memory fragments, high recycling frequency and application pauses and use the traditional flag cleanup method; if the heap is large, it will take a long time to collect. For the optimized scheme, you generally need to refer to the following data, and send garbage collection information, the number of concurrent collection of persistent generations, traditional GC information, and the proportion of time spent on collection of the younger and older generations. Throughput priority applications: general throughput priority applications have a large younger generation and a younger older generation. The reason is that most of the short-term objects can be recycled as much as possible, reducing the number of medium-term objects, while the older generation can store long-term living objects.

3. Fragmentation problems caused by smaller heaps: because the older generation of concurrent collectors use tags and clear algorithms, the heap will not be compressed. When the collector collects, it merges adjacent spaces so that they can be allocated to larger objects. However, when the heap space is small, after running for a period of time, there will be "fragments". If the concurrent collector can not find enough space, then the concurrent collector will stop, and then use the traditional marking to clear the collection. If "fragmentation" occurs, you may need to configure the following:-XX:+UseCMSCompactAtFullCollection: enable the compression of the older generation when using the concurrent collector;-XX:CMSFullGCsBeforeCompaction=0: if the above configuration is enabled, how many times FullGC is set here to compress the older generation.

4. The advantage of using CMS is to use as few new generations as possible, the empirical value is 128M-256M, and then the older generation uses CMS to collect in parallel, which ensures the low latency throughput efficiency of the system. In fact, the collection pause time of cms is very short, 2 GB of memory, about the application pause time of 20-80ms.

5. When the system pauses, it may be a GC problem or a program problem. Use jmap and jstack to check, or killall-3 java, and then check the java console log to see a lot of problems. (the use of related tools will be described later in blog.)

6. Understand your application carefully. If you use cache, the older generation should be older, and the HashMap of cache should not be indefinitely long. It is recommended to use Map of LRU algorithm as cache, and the maximum length of LRUMap should be set according to the actual situation.

7. When using concurrent recycling, the younger generation is younger and the older generation is older, because the elderly use concurrent recycling, even if it takes a long time, it will not affect other programs to continue to run, and the website will not stop.

8. The setting of JVM parameters (especially the setting of parameters such as-Xmx-Xms-Xmn-XX:SurvivorRatio-XX:MaxTenuringThreshold) does not have a fixed formula, which needs to be measured according to the actual YGC times of data in PV old area. In order to avoid that promotion faild may lead to a small xmn setting, it also means an increase in the number of YGC and a decline in the ability to handle concurrent access. Each parameter adjustment needs to go through detailed performance testing in order to find the best configuration for a particular application.

3.3 PromotionFailed:

Promotionfailed is a headache during garbage collection, which may be caused by two reasons. The first reason is that there is not enough rescue space, and the objects in the rescue space should not be moved to the older generation, but there are many objects in the younger generation that need to be put into the rescue space; the second reason is that the older generation does not have enough space to accept objects from the younger generation; both cases will turn to Full GC and the website will be suspended for a long time.

Solution 1:

The first reason is that my final solution is to remove the rescue space and set-XX:SurvivorRatio=65536-XX:MaxTenuringThreshold=0. The second reason is to set CMSInitiatingOccupancyFraction to a certain value (assuming 70%), so that when the space of the older generation reaches 70%, the implementation of CMS starts, and there is enough room for the older generation to accept objects from the younger generation.

Improvements to solution 1:

There are improvements, the above method is not very good, because there is no rescue space, so the elderly generation is easy to fill, CMS implementation will be more frequent. I improved it a little bit. I still use the rescue space, but increase the rescue space so that there will be no promotion failed. Specific operation, 32-bit Linux and 64-bit Linux seem to be different, 64-bit system seems to be configured as long as the MaxTenuringThreshold parameter, CMS is still paused. To solve the pause and promotion failed problems, I finally set-XX:SurvivorRatio=1 and remove the MaxTenuringThreshold so that there is no pause and no promotoin failed, and more importantly, the aging and permanent generations rise very slowly (because many objects are recycled before they reach the old age), so the CMS execution frequency is very low, only once in several hours, so the server does not have to restart.

-Xmx4000M-Xms4000M-Xmn600M-XX:PermSize=500M-XX:MaxPermSize=500M-Xss256K-XX:+DisableExplicitGC-XX:SurvivorRatio=1-XX:+UseConcMarkSweepGC-XX:+UseParNewGC-XX:+CMSParallelRemarkEnabled-XX:+UseCMSCompactAtFullCollection-XX:CMSFullGCsBeforeCompaction=0-XX:+CMSClassUnloadingEnabled-XX:LargePageSizeInBytes=128M-XX:+UseFastAccessorMethods-XX:+UseCMSInitiatingOccupancyOnly-XX:CMSInitiatingOccupancyFraction=80-XX:SoftRefLRUPolicyMSPerMB=0-XX:+PrintClassHistogram-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-XX:+PrintHeapAtGC-Xloggc:log/gc.log

3.4Formula of the relationship between CMSInitiatingOccupancyFraction value and Xmn

The reason for promontionfaild is that when the living objects in EDEN and From survivor are stored in To survivor area when there is insufficient space in EDEN, the space in To survivor area is insufficient, so it is promoted to old gen area again, and when there is not enough memory in old gen area, promontionfaild is generated, which leads to full gc. That can be inferred: eden+from survivor

= (Xmn-Xmn/ (SurvivorRatior+2)) and then infer: CMSInitiatingOccupancyFraction

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.