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

This article introduces the knowledge of "how to use jvm program to execute slow diagnosis manual". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

One of the most common accidents in a production environment is slow program execution, which is characterized by long response times in the case of web services. This article shares the investigation rules that have been formed over the years.

Diagnostic steps system resources view

The first is to view the system resources, and it must be in the first step. Because many accidents are slow at the beginning and then there will be stuck, killed by the system, the program threw an exception to end, and so on, the state at that time can not be saved, can not be reviewed, so the first step is to check the resources of the system, if there is a tense situation, quickly save the state.

Top command

Check that the basic is the top command, you can see the system cpu, memory and other resources. After looking at the system resources, it can be divided into the following situations.

Problem: cpu usage is too high.

If cpu is found to be a bottleneck, you must immediately save the thread situation and the cpu usage at that time. In a bad situation, the cpu may be full, and at that time the ssh can no longer log in and there is no way to get the situation at that time.

Use top-Hp pid to get tid with high thread cpu utilization

Printf "% x\ n" tid, getting the hexadecimal of thread id is mainly for viewing in jstack

Jstack pid | grep tid (16)

Then the thread stack with high thread cpu utilization will be typed out, and then the logic can be analyzed.

Memory utilization is too high or no system resources are occupied too high

Jmap-dump:format=b,file=heapdump.bin pid

The reason why you have to type dump here is that the res is too high, the oom killer of the system may start, and the process may be killed by the system. If you don't get it at this time, the process may be killed. If it is not a problem of system resources, the heap dump will also be used in the future.

Heap occupancy view

Jstat-gc-h 10 pid 1000

Jstat-gcutil-h 10 pid 1000

Jstat-gccause-h 10 pid 1000

Here we usually open three windows to compare the data. -gc is mainly concerned with the total partition size of the heap. -gcutil is mainly concerned with the percentage used. -gccause is mainly concerned with the number of fgc, time and gc reasons.

There are more categories of memory problems, and the root cause of the problem is the gc problem. The virtual machine came to a standstill during stw, resulting in an unresponsive response.

Problem: heap memory footprint is nearly full

In this case, use mat to check the dump analysis, there may be unreasonable memory use or memory leakage, which needs to be analyzed according to the code.

Problem: perm,metaspace occupancy is nearly full

Jps-lvm

Check the jvm parameter setting. It is likely that the parameter setting is unreasonable.-XX:MetaspaceSize is the minimum space in which gc occurs. Is the setting too small here? Whether the value of MaxMetaspaceSize,MaxPermSize is set too small. Java6 if the settings are not small and full, you have to check whether the code is running with strings added to the pool. 1.7 and 1.8 consider whether the business uses some bytecode generation technology and dynamically do some bytecode operations.

Problem: system.gc ()

The reason gccause looks at gc is system.gc (). You need to check whether rmi is used, direct memory is used, or the business code calls system.gc (). There are no ready-made tools for direct memory viewing. You can view it using the gadget I put on github. The address is as follows https://github.com/xpbob/jstatassist

Problem: gc is frequent but not system.gc ()

Space is not particularly tight, but gc is frequent and not system.gc (). That may be because the gc parameters are not set correctly, for example, cms, the old age recycling is a 2-second rotation training operation, it is very likely that the current space occupation meets the conditions of gc every time, so this situation occurs.

Problem: gc takes a long time

Gc time is very long, this from the gc algorithm to choose and memory to coordinate the parameters. But there are two special cases, cms and G1. Both garbage collectors are possible with single-threaded collection algorithms, which need to be confirmed by gc log analysis.

Problem: heap occupancy is small, res is very large

This situation is too likely, the common are jni,jna operations, mmap files, direct memory usage, jdk bug. It needs to be analyzed according to the actual situation.

Problem: business issu

If none of the above performance, then you need to keep typing jstack to see the thread stack changes. This can only be seen in combination with business.

This is the end of the content of "how to use jvm programs to perform slow diagnosis Manual". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.