Commonly used tuning commands and various OOM response strategies [JVM tuning]

1. Common tuning commands

① jps: Display all virtual machine processes;
② jstack: Generate current thread snapshot;
③ jmap: Generate dump heap dump file;
④ jhat: Used with jmap to generate dump analysis results;
⑤ jstat: Monitor the running time of the virtual machine Status information;
⑥ jinfo: View and adjust virtual machine operating parameters in real time.

2. Common performance tuning

① -Xmx: Set the maximum limit of heap memory;
② -XX:NewSize: Set the size of the new generation;
③ -XX:NewRatio: Set the proportion of the new generation and the old generation;
④ Set the garbage collector, use -XX for the new generation :+UseParNewGC, old generation -XX:+UseConcMarkSweepGC.

Insert image description here

3. Commonly used tuning tools

① jconsole: It is the java monitoring and management console that comes with the JDK, used to monitor memory, threads and classes in the JVM; ② jvisualvm, jdk comes with a versatile
tool that can analyze memory snapshots, thread snapshots, and monitor memory changes. , GC changes, etc.;
③ MAT, which is a memory analysis tool based on Eclipse, is a fast and feature-rich Java heap analysis tool, which can help us find memory leaks and reduce memory consumption; ④ GChisto, a professional analysis gc
log Tool of.

4. Various OOM response strategies

(1) Heap memory overflow

What's going on? That is, we continue to create objects, and there is a reachable path from GC Roots to the objects, so the garbage collector will not recycle these objects. When the number of objects in the heap exceeds the maximum heap capacity limit, a memory overflow occurs.

When this kind of exception occurs, we need to dump the heap snapshot file for separate analysis. Then determine whether the object in the memory is necessary to exist, that is, is it a memory leak or a memory overflow?

If it is a memory leak, you can use tools to view its reference chain, analyze what causes useless objects to be referenced for a long time, and then modify the business code; if it is a memory overflow, consider resetting the virtual machine parameters (-Xms, -Xmx).

(2) Stack overflow

Stack overflows easily occur when an application recurses too deeply.

Causes of stack overflow: too deep recursion, a large number of loops, infinite loops or too many global variables, etc.

(3) Constant pool overflow during runtime

Since the constant pool is allocated in the method area, we can limit the size of the method area through -XX:PermSize and -XX:MaxPermSize, thereby indirectly limiting the capacity of the constant pool.

(4) Method area overflow

Check whether some classes are not cached, resulting in frequent loading and generation, and modify the business code for improvement. If the class is loaded normally, we can limit the size of the method area through -XX:PermSize and -XX:MaxPermSize.

5. Configure the garbage collector

① The first is the issue of memory size. Set an upper limit for each memory area. For example, the heap space will be set to 2/3 of the operating system; ②
Next, perform preliminary optimization and set the ratio of the new generation to the old generation reasonably according to the situation. ;
③ Special optimization, based on system capacity, throughput, access delay, etc. Since it is a high-concurrency environment, STW time should be highly valued; ④
Use log analysis tools to quickly locate specific problems.

6. CPU usage is too high

First use the top -Hp command to see which thread occupies the highest CPU, and then use the jstack command to find the specific thread.
If it is a business thread, look for the method that causes high CPU usage; if it is a GC thread, then frequent GC must cause the CPU to rise. At this time, you need to read the logs to find out the reason. You can use the log analysis tool GChisto.

Guess you like

Origin blog.csdn.net/m0_52861684/article/details/132775679