JVM Performance Analysis and Tuning

JVM Performance Analysis and Tuning

1) reasonably configure Parameters

Jvm memory = heap memory + non-heap memory

Heap memory = new generation + Old Generation = 1 Eden zone + 2 vivo VO zones

Non-heap memory = persistent generation + code Cache

 

-Server: server mode. This parameter is placed at the beginning of the configuration item.

-Xms: the initial heap size. The unit is MB.-Xms is the same as-Xmx, which is 80% of the available memory.

-XmX: The maximum heap size, in MB.

-Xmn: the initial size of the new generation, in MB, 3/8 of the heap size

When a file with a large data volume needs to be exported, you need to adjust the values of the following two parameters to avoid OOM

-XX: PermSize: the initial size of the persistent generation, in MB, 1/64 of the physical memory

-XX: MaxPermSize: Maximum persistent generation size, in MB, 1/4 of the physical memory

-Xss: the size of the thread stack, in MB. To adjust the size, 1 ~ is recommended ~ 2 MB

-XX: NewRatio: Ratio of the old generation to the new generation

-XX: Ratio voratio: Ratio of Eden to Vivo Vo

-XX: + HeapDumpOnOutOfMemoryError-XX: HeapDumpPath = path

When the JVM crashes, heap dump can be printed.

-XX: + AggressiveOpts = false: disable this option to prevent the jvm from adding new optimization technologies during jdk version upgrade.

-Djava. awt. headless = true enable this option to solve report incompatibility issues

-XX: + UseCMSCompactAtFullCollection

-XX: + UseInitiatingOccupancyFraction = 80: when the old generation reaches 80%, the CMS garbage collection starts.

-XX: + DisableExplicitGC: The system. gc () call is not allowed ()

-XX: + UseGCOverheadLimit: When garbage collection takes 98% of the time, but the collected memory is less than 2%, the jvm determines that OOM has occurred and can play a warning role.

-XX: + PrintGCDateStamps-verbose: gc. Print the gc details in the log.

-XX: + ExplicitGCInvokesConcurrent-XX: + ExplicitGCInvokesConcurrentAndUnloadsClasses. Enabling this option reduces the lag time of fullgc.

2) gc Process

After an object is generated, it is placed in the Eden area (Eden in young) in the new generation region. If the Eden area is full, the young gc is triggered, objects that cannot be recycled are placed in s (s0 or s1). When s (s0 or s1) is full, the objects are placed in the old region ), if the old area is full, the full gc is triggered, and the object is placed in the perm area ).

Suggestion: do not trigger full gc as frequently as possible. Frequent young gc is normal.

GC garbage collection algorithm:

We recommend that you set the concurrent mark clearing collector (CMS):-XX: + UseConcMarkSweepGC, which reduces the lag time and the probability of fullgc during multi-thread collection and garbage collection, applicable to large response time systems.

Serial GC (-XX: + UseSerialGC): Used in client mode, with the worst performance.

Parallel GC (-XX: + UseParallelGC): multi-threaded collection of invalid and unused objects in the young generation. A single thread collects invalid and unused objects in the old generation.

Parallel Old GC (-XX: + UseParallelOldGC): multi-threaded collection of invalid and unused objects in the young and Old generations.

3) Memory leakage and system overload

Memory leakage: resources used cannot be recycled in a timely manner due to incorrect configurations. You can use the software optimization method to solve this problem.

Symptoms: the memory is about to be fully occupied and at the critical point. The corresponding system logs contain keywords such as OOM.

System overload: There are no more available resources in the system. You can update the hardware.

 

Memory leakage trend chart. After multiple GC operations, the connection trend of multiple low points is rising, indicating Memory leakage.

 

 

 

Common memory leaks include parameter configuration and code.

Common Memory leakage types (configuration)

1) The heap space of the old generation is full. Typical exceptions include: java. lang. outofmemory java heap space

Adjust-Xms M-Xmx M to 80%-Xmn M of available memory to 3/8 of heap size

Free-m

Available memory = free + buffers + cached

2) The persistent Heap Storage space is full. Exceptions include: java. lang. outofmemory java perm space

Adjust-XX: PermSize = M-XX: MaxPermSize = M 1/64 1/4

3) thread stack exception: java. lang. stackoverflowerror stack size too small

Adjusted-Xss = 1 M recommended 1 ~ 2 M

4) The system memory is full.

Java. lang. outofmemoryerror unable to create new native thread

Add memory stick to increase memory size; adjust code to reduce thread creation to reduce memory consumption

Common Memory leakage types (CODE)

1) objects cannot be recycled (static type)

2) The database connection is not closed.

 

4) use command Monitoring and Analysis

A) view the command for running the java Process on jvm: jps-ml

B) view jvm performance statistics including GC statistics: jstat-gcutil 5S 5

C) view heap memory ing information: jmap

Prints shared object memory ing or heap memory details of a specified java Process, core file, and remote call server.

Jmap-heap pid

Jmap-histo: live pid

Jmap-dump: live, format = B, file =./yyyy-mm-dd.hprof pid

D) view the thread stack trace information: jstack

Prints the trace information of the thread stack of the specified java Process, core file, and remote call server.

Process for locating and analyzing hotspot CPUs

Jps pid

Top-Hp pid or ps-mp pid-o THREAD, tid, time

Printf "% x \ n" tid

Jstack pid | grep hexadecimal tid-A 30

5) use tools for monitoring and analysis

To monitor the remote tomcat service, you must add the configuration in catalina. sh to optimize the configuration according to the actual situation.

JAVA_OPTS = "-server-Xms595M-Xmx595M-Xmn223M-XX: PermSize = 10 M-XX: MaxPermSize = 20 M"

Add configuration items.

-Djava. rmi. server. hostname = 192.168.96.128

-Dcom. sun. management. jmxremote

-Dcom. sun. management. jmxremote. port = 1235-Dcom. sun. management. jmxremote. authenticate = false-Dcom. sun. management. jmxremote. ssl = false

Tool description:

Jconsole: monitors CPU usage, heap memory usage, classes, and thread usage on local and remote machines, analyzes whether deadlocks exist, and supports garbage collection.

Jvisualvm: monitors CPU usage, heap memory, classes, and threads on local and remote machines, and analyzes whether deadlocks exist, supports garbage collection, thread dump, heap dump, analysis thread dump, heap dump, application snapshot, and profile snapshot files to detect problems. Connecting ip: port through jmx

MemoryAnalyzer: A memory analysis tool that analyzes hprof files generated by heap dump and jcmd dump files in jvisualvm. In the details Report of opened dump files, check whether the Thread has deadlocks and other errors in the Thread Stack.