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

1. Enable GC log

1. Under the installation path of Tomcat, find bin/catalina.sh plus the following configuration, and configure the specific parameters yourself:

[root@centos7 tomcat] # vim bin/catalina.sh

The copy code is as follows: JAVA_OPTS='-Xms512m-Xmx4096m-XX:PermSize=64M-XX:MaxNewSize=128m-XX:MaxPermSize=64m-XX:ParallelGCThreads=8-XX:+UseConcMarkSweepGC-Xloggc:/usr/local/tomcat/logs/tomcat_gc.log'

2. Restart tomcat

[root@centos7 ~] # systemctl restart tomcat

3. View the GC log

[root@centos7 ~] # cat/ usr/local/tomcat/logs/tomcat_gc.log

If you just use it and understand the configuration, you only need to look at the second, third and fourth. If you want to learn more about GC, please read it in detail.

II. GC log analysis

For GC log analysis, you need to use windows's GC log analysis tool gchisto

Source download address of gchisto tool: http://xz.jb51.net:81/201806/yuanma/GChisto_jb51.rar

1. Windows installs java environment

(1) go to the official website to download the JDK version you want.

Http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

Download, you must click to agree to the agreement

(2) install JDK1.8 version

Set your own installation path and cancel the announcement JRE

(3) set 3 environment variables

① found the bin path where he installed jdk. My installation path is C:\ Program Files (x86)\ Java\ jdk1.8.0_171.

② in Advanced system Settings-> Environment variables-> New

Create 2 new environment variables:

JAVA_HOME

CLASSPATH

Modify a variable: Path

(4) after installation and testing

The java, javac, and java-version commands have the following effects

2. Run gchisto and analyze the gc log

(1) run gchisto

After unpacking, open the cmd command line and execute the following command. Note: the path of gchisto after unpacking by yourself.

> java-jar D:\ gchisto-master\ release\ GCHisto-java8.jar

(2) effect after opening

(3) analyze the gc log of Tomcat

① sz the tomcat log under linux to windows

Import ② into gchisto

View the effect of ③

Third, detailed explanation of option parameters 1. Heap size setting

①-Xmx3550m-Xms3550m-Xmn2g-Xss128k

-Xmx3550m: set the maximum available memory of JVM to 3550m.

-Xms3550m: set the initial memory of JVM to 3550m. This value can be set to the same as-Xmx to prevent JVM from reallocating memory after each garbage collection.

-Xmn2g: set the size of the younger generation to 2G. Whole heap size = young generation size + old generation size + lasting generation size. 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.

-Xss128k: 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:NewRatio=4-XX:SurvivorRatio=4-XX:MaxPermSize=16m-XX:MaxTenuringThreshold=0

-XX:NewRatio=4: sets the ratio of the younger generation (including Eden and two Survivor zones) to the older generation (excluding the persistent generation). If set to 4, the ratio of the younger generation to the older generation is 1:4, and the younger generation accounts for 1 prime 5 of the whole stack.

-XX:SurvivorRatio=4: sets the ratio of the size of the Eden region to the Survivor region in the younger generation. If set to 4, the ratio of two Survivor regions to one Eden region is 2:4, and one Survivor region accounts for 1 prime 6 of the whole young generation.

-XX:PermSize: sets the perm gen initial value. The default value is 1 stroke 64 of physical memory.

-XX:MaxPermSize: sets the maximum persistent generation. 1x4 of physical memory.

-XX:MaxTenuringThreshold=0: set the maximum age of garbage. If set to 0, the younger generation will enter the older generation without going through the Survivor area. For more applications of the older generation, it can improve the efficiency. If you set this value to a large value, the younger generation object will be replicated multiple times in the Survivor area, which can increase the survival time of the younger generation of the object and increase the overview of being recycled in the younger generation.

2. Recycler selection

(1) Throughput priority parallel collector

①-XX:+UseParallelGC-XX:ParallelGCThreads=20

-XX:+UseParallelGC: select the garbage collector as the parallel collector. This configuration is valid only for the younger generation. That is, in the above configuration, the younger generation uses concurrent collection, while the older generation still uses serial collection.

-XX:ParallelGCThreads=20: configure the number of threads in the parallel collector, that is, how many threads perform garbage collection at the same time. This value is preferably configured equal to the number of processors.

②-XX:+UseParallelOldGC

-XX:+UseParallelOldGC: configure the old generation garbage collection method to collect in parallel. JDK6.0 supports parallel collection of older generations.

③-XX:MaxGCPauseMillis=100

-XX:MaxGCPauseMillis=100: set the maximum time for each young generation garbage collection. If this time cannot be met, JVM will automatically adjust the size of the younger generation to meet this value.

④-XX:+UseAdaptiveSizePolicy

-XX:+UseAdaptiveSizePolicy: when this option is set, the parallel collector automatically selects the size of the younger generation area and the corresponding Survivor area ratio to achieve the minimum corresponding time or collection frequency specified by the target system. This value is recommended to be turned on when using the parallel collector.

(2) concurrent collector with priority response time

①-XX:+UseConcMarkSweepGC-XX:+UseParNewGC

-XX:+UseConcMarkSweepGC: set the older generation to collect concurrently. After configuring this in the test, the configuration of-XX:NewRatio=4 failed for an unknown reason. Therefore, at this time, the size of the younger generation is best set with-Xmn.

-XX:+UseParNewGC: set the younger generation to collect in parallel. Can be used in conjunction with CMS collection. Above JDK5.0, JVM will be set according to the system configuration, so it is no longer necessary to set this value.

②-XX:CMSFullGCsBeforeCompaction=5-XX:+UseCMSCompactAtFullCollection

-XX:CMSFullGCsBeforeCompaction: because the concurrent collector does not compress or clean up the memory space, it will produce "fragments" after running for a period of time, which reduces the running efficiency. This value sets how many times to run GC to compress and organize the memory space.

-XX:+UseCMSCompactAtFullCollection: turn on the compression of the older generation. May affect performance, but can eliminate fragmentation

3. Auxiliary information

JVM provides a large number of command-line parameters and print information for debugging. The main points are as follows:

①-XX:+PrintGC

Output form:

[GC 118250K-> 113543K (130112K), 0.0094143 secs]

[Full GC 121376K-> 10414K (130112K), 0.0650971 secs]

②-XX:+PrintGCDetails

Output form:

[GC [DefNew: 8614K-> 781K (9088K), 0.0123035 secs] 118250K-> 113543K (130112K), 0.0124633 secs]

[GC [DefNew: 8614K-> 8614K (9088K), 0.0000665 secs] [Tenured: 112761K-> 10414K (121024K), 0.0433488 secs] 121376K-> 10414K (130112K), 0.0436268 secs]

③-XX:+PrintGCTimeStamps-XX:+PrintGC:PrintGCTimeStamps can be mixed with the above two

Output form:

11.851: [GC 98328K-> 93620K (130112K), 0.0082960 secs]

④-XX:+PrintGCApplicationConcurrentTime: prints the uninterrupted execution time of the program before each garbage collection. Can be mixed with the above

Output form:

Application time: 0.5291524 seconds

⑤-XX:+PrintGCApplicationStoppedTime: the time the program was paused during print garbage collection. Can be mixed with the above

Output form:

Total time for which application threads were stopped: 0.0468229 seconds

⑥-XX:PrintHeapAtGC: detailed stack information before and after printing GC

Output form:

34.702: [GC {Heap before gc invocations=7:

Def new generation total 55296K, used 52568K [0x1ebd0000, 0x227d0000, 0x227d0000)

Eden space 49152K, 99% used [0x1ebd0000, 0x21bce430, 0x21bd0000)

From space 6144K, 55% used [0x221d0000, 0x22527e10, 0x227d0000)

To space 6144K, 0% used [0x21bd0000, 0x21bd0000, 0x221d0000)

Tenured generation total 69632K, used 2696K [0x227d0000, 0x26bd0000, 0x26bd0000)

The space 69632K, 3% used [0x227d0000, 0x22a720f8, 0x22a72200, 0x26bd0000)

Compacting perm gen total 8192 K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)

The space 8192 K, 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)

Ro space 8192 K, 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)

Rw space 12288K, 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)

34.735: [DefNew: 52568K-> 3433K (55296K), 0.0072126 secs] 55264K-> 6615K (124928K) Heap after gc invocations=8:

Def new generation total 55296K, used 3433K [0x1ebd0000, 0x227d0000, 0x227d0000)

Eden space 49152K, 0% used [0x1ebd0000, 0x1ebd0000, 0x21bd0000)

From space 6144K, 55% used [0x21bd0000, 0x21f2a5e8, 0x221d0000)

To space 6144K, 0% used [0x221d0000, 0x221d0000, 0x227d0000)

Tenured generation total 69632K, used 3182K [0x227d0000, 0x26bd0000, 0x26bd0000)

The space 69632K, 4% used [0x227d0000, 0x22aeb958, 0x22aeba00, 0x26bd0000)

Compacting perm gen total 8192 K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)

The space 8192 K, 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)

Ro space 8192 K, 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)

Rw space 12288K, 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)

}

, 0.0757599 secs]

⑦-Xloggc:filename: use in conjunction with the above to record relevant log information to a file for analysis.

Fourth, common configuration summary 1, heap settings

①-Xms: initial heap size

②-Xmx: maximum heap size

③-XX:NewSize=n: sets the size of the younger generation

④-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.

⑤-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.

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

2. Collector settings

①-XX:+UseSerialGC: setting the serial collector

②-XX:+UseParallelGC: setting up parallel collectors

③-XX:+UseParalledlOldGC: setting up parallel older collectors

④-XX:+UseConcMarkSweepGC: setting up concurrent collectors

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 setting the young generation collection mode of the concurrent collector to parallel collection. Number of threads collected in parallel.

Fifth, tuning summary 1. Selection of the size of the younger generation

① response time priority applications: set as large as possible until close to the system's minimum response time limit (choose according to the actual situation). In this case, the frequency of collection of the younger generation is also the lowest. At the same time, reduce the number of people who 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.

2. Choice of the size of the older generation

① response time priority applications: the older generation uses concurrent collectors, so its size needs to be set carefully, generally considering some parameters such as concurrent session rate and session duration. If the heap setting is small, it can cause memory fragmentation, high recycling frequency, and application pauses and use the traditional flag cleanup method; if the heap is large, it takes a long time to collect. For the most optimized scheme, you generally need to refer to the following data:

Concurrent garbage collection information

Number of concurrent collections of persistent generations

Traditional GC information

The proportion of time spent on recycling between the younger generation and the older generation

Reducing the time spent by the younger and older generations will generally improve the efficiency of the application.

② throughput priority applications: generally speaking, 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. Debris problems caused by smaller heaps

Because the older generation of concurrent collectors use marking and clearing algorithms, the heap is not 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 cannot find enough space, then the concurrent collector will stop and then recycle it using the traditional marking and clearing methods. If there is a "fragment", you may need to configure as follows:

①-XX:+UseCMSCompactAtFullCollection: enables compression of the older generation when using a concurrent collector.

②-XX:CMSFullGCsBeforeCompaction=0: when the above configuration is enabled, how many times the FullGC is set here to compress the older generation

VI. Related concepts 1. Detailed description of generation-by-generation garbage collection

(1) Young (younger generation)

The younger generation is divided into three districts. One Eden zone and two Survivor zones. Most objects are generated in the Eden zone. When the Eden area is full, the surviving objects will be copied to the Survivor area (one of the two), when the Survivor area is full, the surviving objects in this area will be copied to another Survivor area, and when the Survivor is full, the objects copied from the first Survivor area and still alive at this time will be copied "Tenured". It should be noted that the two regions of Survivor are symmetrical and have no sequential relationship, so there may be objects copied from Eden and objects copied from the previous Survivor in the same area, while objects copied to the old zone are only objects copied from the first Survivor. Also, one of the Survivor zones is always empty.

(2) Tenured (older generation)

The older generation stores objects that survive from the younger generation. Generally speaking, the older generation stores objects with a longer life span.

(3) Perm (persistent generation)

Used to store static files, now Java classes, methods, and so on. Persistent generation has no significant impact on garbage collection, but some applications may dynamically generate or call some class, such as Hibernate, at this time, you need to set a large persistent generation space to store these new classes. The persistent generation size is set through-XX:MaxPermSize=.

2. GC type

There are two types of GC: Scavenge GC and Full GC.

(1) Scavenge GC

In general, when a new object is generated and the Eden fails to apply for space, the Scavenge GC is triggered, the heap Eden area is GC, the non-living objects are cleared, and the living objects are moved to the Survivor area. Then sort out the two districts of Survivor.

(2) Full GC

Organize the entire heap, including Young, Tenured, and Perm. Full GC is slower than Scavenge GC, so Full GC should be reduced as much as possible. Full GC can occur for the following reasons:

Tenured is full Perm fields are full System.gc () is shown that the allocation policies of Heap domains have changed dynamically since the last call to GC. 3. Garbage collector

At present, there are mainly three kinds of collectors: serial collector, parallel collector and concurrent collector.

(1) Serial collector

Using a single thread to handle all garbage collection work is more efficient because there is no need for multithreaded interaction. However, it is also impossible to take advantage of multiprocessors, so this collector is suitable for single-processor machines. Of course, this collector can also be used on multiprocessor machines with a small amount of data (about 100m). You can open it using-XX:+UseSerialGC.

(2) parallel collector

Parallel garbage collection for the younger generation, so garbage collection time can be reduced. It is generally used on multithreaded multiprocessor machines. Use-XX:+UseParallelGC. open. The parallel collector was introduced in the J2SE5.0 666 update and enhanced in Java SE6.0-it can be collected in parallel with the older generation. If the older generation does not use concurrent collection, it uses a single thread for garbage collection, which restricts scalability. Open it using-XX:+UseParallelOldGC.

Use-XX:ParallelGCThreads= to set the number of threads for parallel garbage collection. This value can be set equal to the number of machine processors.

This collector can be configured as follows:

Maximum XX:MaxGCPauseMillis= pause: specify the maximum pause time for garbage collection, specified by-time. For milliseconds. If this value is specified, the heap size and garbage collection related parameters are adjusted to reach the specified value. Setting this value may reduce the throughput of the application. Throughput: the throughput is the ratio of garbage collection time to non-garbage collection time, which is set by-XX:GCTimeRatio=. The formula is 1 / (1mm N). For example, when-XX:GCTimeRatio=19, it means 5% of the time is spent on garbage collection. The default is 99, or 1% of the time is spent on garbage collection.

(3) concurrent collector

It can ensure that most of the work is carried out concurrently (the application does not stop), and garbage collection only pauses for a little time. This collector is suitable for medium and large-scale applications that require high response time. Open it using-XX:+UseConcMarkSweepGC.

The concurrent collector mainly reduces the pause time of the older generation, using a separate garbage collection thread to track reachable objects without stopping the application. In each annual old generation garbage collection cycle, the concurrent collector briefly pauses the entire application at the beginning of the collection and pauses again during the collection. The second pause is slightly longer than the first, during which multiple threads perform garbage collection at the same time. The concurrent collector uses the processor in exchange for a short pause. On an N-processor system, the concurrent collection part is recycled using N available processors, usually 1.

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.