Find Java code with high CPU consumption and memory overflow through thread dump analysis

http://heylinux.com/archives/1085.html using thread dump analysis to find Java code with high CPU consumption and memory overflow

First of all, I want to thank my good friend Zhao to share the experience of the flower.

I believe that in the actual work, you will certainly encounter high CPU consumption and memory overflow caused by the code.
Usually when this happens, we take it for granted that the developer solves the problem by itself, because there is no problem with the operating system environment.

But in fact, we can help them, the effect of good words can also be targeted to the specific problem of the number of lines of code, the idea is as follows:
1. Determine if there is a problem with CPU and memory consumption;
2. Find the ID of the suspect thread through the top command;
3. Confirm the output location of the console information of the application server;
4. Obtain thread dump information by kill-3 ID;
5. Back up the console log and check the code-related information through the thread ID.

Below, we begin the specific operation process:

1. Determine if there is a problem with CPU and memory consumption;
The CPU can be judged directly in the top of the CPU%us value can be, usually under 50% is normal, once more than 60% or even high to 80-90 and stable, then there must be a problem;
When judging memory, it is important to look directly at the first line of mem: The used value is not accurate, because usually after a period of time, this value will be very large, because the Linux memory usage concept "memory is used", it will use the free memory as much as possible cache, to improve performance, So we should refer more-/+ Buffers/cache: This line of used value, if the value and the first row of the used value is very close to the total memory difference, then the memory is in a tense state;
Virtual memory consumption is also worth reference, Linux only if the memory is not enough to use the virtual memory, if the virtual memory use value of 0 or about 100 trillion, then you can determine the physical memory is sufficient;
The value of the system load is also well worth reference, that is, the load average in top, usually less than 1 represents very good, 1-5 is normal, more than 5 indicates that the system is in a state of load, the larger the value of the greater the load.

2. Find the ID of the suspect thread through the top command;
Execute the top command, enter the uppercase "H" in the Linux task Manager to open the threading mode, and then all threads will be sorted by CPU consumption by default;
If you want to sort by memory, and then the uppercase "M", where "RES" sees the amount of physical memory consumed, but because of the thread's shared memory principle, we see that each thread has the same amount of memory as the process in which they belong.

3. Confirm the output location of the console information of the application server;
Typically, the console information for the application server is output to log, such as Tomcat output to the Catalina.out file.
However, JBoss and WebLogic need to make some modification settings, which:
JBoss If you use the official startup script, you need to modify the/dev/null in the following two lines of the startup script to change it to the specified log file location, such as/opt/jboss_console.log, and then restart JBoss.
---------------------------------------------------------------------
Jboss_console= "/dev/null"

jboss_console=${jboss_console:-"/dev/null"}
---------------------------------------------------------------------

WebLogic needs to be in the console admin interface "domain Structure"-"environment"-"zone"-"Server"-"AdminServer"-"Logging"-"advanced"-tick "redirected standard output logging started", and then click "Activate Changes" and restart WebLogic. All console information will then be output to the AdminServer.log file in the logs directory.

4. Obtain thread dump information by kill-3 ID;
After confirming the console information output of the application server and locating the suspect thread ID, execute the kill-3 ID to output all thread dump information for this moment to log.
It is recommended that the command be executed several times to obtain sufficient information.

5. Back up the console log and check the code-related information through the thread ID.
After executing the thread dump information output, immediately use the CP command to back up the log file,
Download the log file locally, convert the process ID into 16, such as 29433 conversion to 16 is 72f9;
Open the log file (we recommend using an editor such as UE or notepad++), search for information that contains 72F9, and then double-check the relevant code.

Take my situation as an example:
The following piece of information contains "NID=0X72F9", indicating that it is related to process 29433, that the mentioned Jioendpoint.java is the actual code file, and the next 442 represents the specific number of rows.
---------------------------------------------------------------------
"http-0.0.0.0-80-78" daemon prio=10 tid=0x00000000686db800 nid=0x72f9 in object.wait () [0x000000004cea6000]
Java.lang.Thread.State:WAITING (on object monitor)
At java.lang.Object.wait (Native Method)
-Waiting on <0x00002aab0bccd5b8> (a org.apache.tomcat.util.net.jioendpoint$worker)
At Java.lang.Object.wait (object.java:485)
At Org.apache.tomcat.util.net.jioendpoint$worker.await (jioendpoint.java:416)
-Locked <0x00002aab0bccd5b8> (a org.apache.tomcat.util.net.jioendpoint$worker)
At Org.apache.tomcat.util.net.jioendpoint$worker.run (jioendpoint.java:442)
At Java.lang.Thread.run (thread.java:619)
---------------------------------------------------------------------

In this case, the actual work has just begun, requiring the developer to carefully examine all the similar information and then identify the problematic code.

There is data that the role of thread dump in fact there are many, you can find many applications running problems, such as deadlocks, and there is an Eclipse plug-in visual analysis tool "Lockness" can be more professional analysis of this type of log.links to articles about this topichttp://blog.csdn.net/gobitan/article/details/5474062

Find Java code with high CPU consumption and memory overflow through thread dump analysis