Shulou(Shulou.com)06/02 Report--

This article introduces what JVM memory tuning is, the content is very detailed, interested friends can refer to, hope to be helpful to you.

Premise:

The development of a large cross-border e-commerce business is very fast, and the capacity of online machines is also very frequent, but for the operation of online machines, especially in the case of jvm memory, there has not been a unified standard to give each application service owner. After 618 promotion, I discussed with the students of operation and maintenance, hoping to standardize the jvm parameters of online servers so that they can be given to various applications in a unified way, so as to improve the stability of online servers and reduce the time for everyone to adjust jvm parameters.

Refer to the experience of the company that worked in Taobao Tmall before: after discussion, according to the version of jdk and the configuration of the online machine, we determined a recommended default jvm template:

The final recommended jvm template:

Jdk version of machine configuration recommended jvm parameters remarks

Jdk1.7 6V8G-server-Xms4g-Xmx4g-Xmn2g-Xss768k-XX:PermSize=512m-XX:MaxPermSize=512m-XX:+UseConcMarkSweepGC-XX:+CMSClassUnloadingEnabled-XX:+DisableExplicitGC-XX:+UseCMSInitiatingOccupancyOnly-XX:CMSInitiatingOccupancyFraction=68-verbose:gc-XX:+PrintGCDetails-Xloggc: {CATALINA_BASE} / logs/gc.log-XX:+PrintGCDateStamps-XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath= {CATALINA_BASE} / logs Front desk

Jdk1.7 8V8G-server-Xms4g-Xmx4g-Xmn2g-Xss768k-XX:PermSize=512m-XX:MaxPermSize=512m-XX:+UseConcMarkSweepGC-XX:+CMSClassUnloadingEnabled-XX:+DisableExplicitGC-XX:+UseCMSInitiatingOccupancyOnly-XX:CMSInitiatingOccupancyFraction=68-verbose:gc-XX:+PrintGCDetails-Xloggc: {CATALINA_BASE} / logs/gc.log-XX:+PrintGCDateStamps-XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath= {CATALINA_BASE} / logs Front desk

Jdk1.7 4V8G-server-Xms4g-Xmx4g-Xmn2g-Xss768k-XX:PermSize=512m-XX:MaxPermSize=512m-XX:+UseConcMarkSweepGC-XX:+CMSClassUnloadingEnabled-XX:+DisableExplicitGC-XX:+UseCMSInitiatingOccupancyOnly-XX:CMSInitiatingOccupancyFraction=68-verbose:gc-XX:+PrintGCDetails-Xloggc: {CATALINA_BASE} / logs/gc.log-XX:+PrintGCDateStamps-XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath= {CATALINA_BASE} / logs Front desk

Jdk1.7 6V8G-server-Xms4g-Xmx4g-XX:MaxPermSize=512m\

-verbose:gc-XX:+PrintGCDetails-Xloggc {CATALINA_BASE} / logs/gc.log-XX:+PrintGCTimeStamps\ backend

The recommended configuration of an bat company:

Configuration instructions:

1. Heap settings

O-Xms: initial heap size

O-Xmx: maximum heap size

O-XX:NewSize=n: set the size of the younger generation

O-XX:NewRatio=n: sets the ratio of the younger generation to the older generation. For example, 3 means that the ratio of the young generation to the old generation is 1:3, and the young generation accounts for 1% of the sum of the young generation and the old generation.

O-XX:SurvivorRatio=n: the ratio of Eden region to two Survivor regions in the young generation. Notice that there are two in the Survivor area. For example: 3, which means Eden:Survivor=3:2, and one Survivor area accounts for 1x5 of the whole younger generation.

O-XX:MaxPermSize=n: sets the persistent generation size

two。 Collector Settings

O-XX:+UseSerialGC: set the serial collector

O-XX:+UseParallelGC: setting up parallel collectors

O-XX:+UseParalledlOldGC: setting up parallel older generation collectors

O-XX:+UseConcMarkSweepGC: setting up the concurrent collector

3. Garbage collection statistics

-XX:+PrintGC

-XX:+PrintGCDetails

-XX:+PrintGCTimeStamps

-Xloggc:filename

"

4. Parallel Collector Settings

-XX:ParallelGCThreads=n: sets the number of CPU to use when collecting by the parallel collector. Number of threads collected in parallel.

-XX:MaxGCPauseMillis=n: sets the maximum pause time for parallel collection

-XX:GCTimeRatio=n: sets the percentage of garbage collection time to program running time. The formula is 1 / (1cm n)

5. Concurrent Collector Settings

-XX:+CMSIncrementalMode: set to incremental mode. It is suitable for single CPU situation.

-XX:ParallelGCThreads=n: the number of CPU used when the young generation of the concurrent collector is collected in parallel. Number of threads collected in parallel.

(4)

Parameter explanation:

-Xms3072m-Xmx3072m

For the setting of JVM heap, the minimum and maximum values are defined by-Xms-Xmx

-Xmn1024m sets the size of the younger generation to 1024m

Total JVM memory size = younger generation size + older generation size + persistent generation size (perm).

-Xss768k sets the stack size for each thread. The stack size of each thread after JDK5.0 is 1m, and the stack size of each thread before is 256K. Adjust the amount of memory required by more applicable threads. 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.

-XX:PermSize=512m-XX:MaxPermSize=512m

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.

Set the initial value of non-heap memory, default is 1x64 of physical memory; XX:MaxPermSize sets the maximum size of non-heap memory, default is 1x4 of physical memory

-XX:+UseConcMarkSweepGC

The CMS collector is also known as a short pause concurrent collector. It collects garbage for the elderly. The CMS collector performs garbage collection through multi-thread concurrency to minimize the pause caused by garbage collection. The CMS collector uses the same algorithm for garbage collection for the younger generation as the Parallel collector. This garbage collector is suitable for applications that cannot tolerate long pauses for quick response.

-XX:+UseParNewGC uses multi-thread parallel recovery for the younger generation, so it can be collected quickly.

-XX:+CMSClassUnloadingEnabled

If you enable CMSClassUnloadingEnabled, garbage collection will clean up the persistent generation and remove classes that is no longer in use. This parameter is useful only if UseConcMarkSweepGC is also enabled.

-XX:+DisableExplicitGC forbids System.gc () to prevent programmers from mistakenly calling the gc method to affect performance

-XX:+UseCMSInitiatingOccupancyOnly

Flag to command JVM not to start the CMS garbage collection cycle based on the data collected at run time. Instead, when the flag is turned on, JVM makes every CMS collection through the value of CMSInitiatingOccupancyFraction, not just the first time. Keep in mind, however, that in most cases, JVM can make better garbage collection decisions than we can. Therefore, this flag should be used only if we have good reasons (such as testing) and have a deep understanding of the life cycle of the objects generated by the application.

-XX:CMSInitiatingOccupancyFraction=68

The default CMS is to start CMS collection when tenured generation (older generation) accounts for 68%. If your older generation is not growing so fast and you want to reduce the number of CMS, you can increase this value appropriately.

-XX:+UseParNewGC: multi-thread parallel recycling is used for the younger generation, so that the collection is fast.

-XX:HeapDumpPath

-XX:+PrintGCDetails

-XX:+PrintGCTimeStamps

-Xloggc:/usr/aaa/dump/heap_trace.txt

The above parameters type Heap Dump information

"> this parameter controls the information of the print heap during OutOfMemoryError.

As you may have noticed, cms is recommended for garbage collection.

CMS is a collector that aims to obtain the shortest recovery pause time, which can effectively reduce the server pause time.

The GC thread of CMS will have a high occupancy rate of CPU, but it still shows superior characteristics on multi-core servers, and it is also deployed on major domestic e-commerce websites. So it is highly recommended here!

The concept of cms:

The CMS collector is also known as a short pause concurrent collector. It collects garbage for the elderly. The CMS collector performs garbage collection through multi-thread concurrency to minimize the pause caused by garbage collection. The CMS collector uses the same algorithm for garbage collection for the younger generation as the Parallel collector. This garbage collector is suitable for applications that cannot tolerate long pauses for quick response. CMS uses a variety of ways to reduce the pause time of GC as much as possible and reduce the pause of user programs. The pause time is reduced at the expense of CPU throughput. This is a trade-off between pause time and performance, which can be simply understood as "space (performance)" for time.

The rhythm of adjustment:

For fear of affecting online applications, the adjustment steps are divided into three steps:

The first step: partially affect a small number of machine pilots, compare the unadjusted machines, and observe the adjusted results

The second step: adjust some of the applied parameters, carry out pressure test, and observe the effect after high concurrent pressure test.

Step 3: adjust the jvm parameters of some core applications to actually test the effect.

At present, the 818 promotion has been achieved. Just in time to sum up one by one.

One: long-term performance

The first change: the number of fgc has decreased, more than doubled

For the mobile project, there are basically 1-2 cars a day before the adjustment, and once every 2-3 days after the adjustment:

Online (another project): you can obviously see that the statistical frequency of fgc is much less.

The methods that can be used are:

The purpose of starting ygc before CMS GC is to reduce the reference of old gen to ygc gen and reduce the overhead of remark-generally 80% of the GC time of CMS is in the remark phase.

-XX:+CMSScavengeBeforeRemark

Jmap Analysis:

Problem 4: OutOfMemoryError caused by the occupation of DirectMemory by nio framework

How to handle it: using XX:+DisableExplicitGC

Increase the size of DirectMemory

1. DirectMemory does not belong to java heap memory. Allocating memory is actually a call to the operating system's Os:malloc () function.

2. The capacity can be specified by-XX:MaxDirectMemorySize. If not, the default value is the same as the maximum value of the Java heap (specified by-Xmx). Note that the ibm jvm default Direct Memory is not directly related to-Xmx.

3. The use of Direct Memory memory avoids copying data back and forth in Java heap and Native heap. Improve performance from some scenarios.

4. Direct ByteBuffer objects automatically clean the native buffer, but this process can only be performed as part of the Java heap GC, so they do not automatically respond to the pressure exerted on the native heap.

5. GC occurs only when the Java heap is so full that it cannot serve heap allocation requests, or when the Java application shows a call to the System.gc () function to free memory (some NIO frameworks use this method to release occupied DirectMemory).

6. Unreasonable use in this area will also cause OutOfMemoryError.

7. In situations where Buffer needs to be created frequently, it is not appropriate to use DirectBuffer because of the high cost of creating and destroying DirectBuffer. However, if DirectBuffer can be reused, it can greatly improve performance in the case of frequent read and write. (DirectBuffer reads and writes faster than normal Buffer, but its creation and destruction is slower than normal Buffer.)

About what JVM memory tuning is shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.