Online server CPU 100%, how to troubleshoot the problem? Some fans wrote me a message asking if they could explain it with a case study, which led to this article.

It is assumed that you know the run-time data areas and common garbage collection algorithms, as well as the garbage collector supported by Hotspot

Scenario 1: The CPU usage is too high

If the CPU usage is too high, it should be discussed in different situations. If there is a large amount of traffic during an activity and the CPU usage decreases after the activity is over, it is not necessary to care too much, because the more requests, the more threads need to be processed. This is a normal phenomenon. On the other hand, if you have a poorly configured server with a single CPU core, and a little more traffic can really drain your CPU, you should consider upgrading your configuration first.

CPU usage is chronically too high, in this case it could be that your program has code that loops too many times, or even has an infinite loop, or a deadlock. How to troubleshoot and locate problems at this time?

  • Run the top command to check the CPU usage

This allows you to locate processes with high CPU usage. On Linux, the top command obtains the same process id as the VMID obtained by the JPS tool.

  • Run the top-hp command to check the status of the thread

You can see that thread ID 23835 has been occupying CPU

  • Convert the thread number to hexadecimal

Write down this hexadecimal number, which we’re going to use

  • Use the JStack tool to view the thread stack.

See previous articles for details

  • Use Arthas’s thread command to view the thread stack

I’m going to use the Arthas thread command to check the stack for the current thread

Output the current thread stack by jstack tool, and locate the running status of this thread through grep command combined with the hexadecimal ID of the thread obtained in the previous step, where 23835 after jstack is the process number located in step (1), and the thread number located in step (2) and (3) after grep. You can see from the output that the thread is running

Case code

Scenario 2: Program deadlock

Deadlock is not as obvious as the first scenario. The Web application must be a multithreaded program, which serves multiple requests. After the program is deadlocked, the thread in the deadlock state is in WAITING state (WAITING or TIMED_WAITING). I ran out of time. When deadlock cases are rare, they are not easily detected.

  • Open the Arthas view thread

  • View thread information by CPU usage

  • Displays the running heap for the specified thread

A deadlock was found, and it’s easy to see why

Case code

conclusion

These are not exactly JVM tuning, but JVM tools are used to find problems in your code. Our main goal with the JVM is to minimize pause times and improve system throughput. However, if we blindly set the parameters without analyzing the system, we can get worse results. As the JVM develops today, the various default parameters may be balanced by people in the lab after many tests, which is suitable for most application scenarios. If you think your JVM really needs to be tuned, by all means sample it, and then slowly tune it several times to get better results.

The author | wisdom elder brother

The original link

More technical dry goods please pay attention to code agriculture architecture technology number: code agriculture architecture – nuggets

This article is the original content of the code farm, and shall not be reproduced without permission.