IBM WebSphere Javacore Analysis __java

Today, the company's server down, throw a lot of javacore files, this file is better analysis, let's talk about what is Javacore, and how to analyze Javacore file to find out the problem.

Reference http://zhangzhiqiangli.blog.163.com/blog/static/459183842012715111949106/

One, what is Javacore.

Javacore is a text representation of a Java application at one time, or a thread dump file that is known as a Java dump (usually called thread dump). This file records the operation of the entire JVM, including information such as threads, garbage collection, JVM run parameters, memory addresses, and so on. Many of the JVM's problems can be diagnosed with this file, which typically includes issues such as thread blocking, high CPU usage, JVM Crash, low heap memory, and class loading.

Javacore files are usually displayed in *.txt, with the name format mainly Javacore as the header, with the date number, the resulting time number, and the thread number at the time, such as: Javacore.20100719.003424.299228.txt.

We can get javacore in the following ways:

1. Send an aborted signal to the operating system

http://blog.csdn.net/happyqwz/article/details/8255762

2. Use the Javadump () method in Java execution code

The Com.ibm.jvm.Dump.JavaDump () method prompts the JVM Dump

Publish the Problemdiagnosticslabtoolkit application package and generate the related files directly from the visual page.

3. The system automatically throws when abnormal

? A serious local call error (non-Java exception)

? The JVM heap is running out of size

? OutOfMemory Error

Second, Javacore describes what the content.

With the help of javacore files, we can better analyze the operation of the system, in the system deadlock, or internal errors, middleware and other issues, we can further in-depth analysis through Javacore. We can find the following relevant information in the Javacore file:

? Parameter startup parameters for the JVM, JDK version

? JVM Heap Size

? JVM generation Reason, generation time (can be manually obtained, can be thrown by system)

? Last detailed garbage collection record when the number of global garbage collections, allocation failures, and memory overflows

? JVM Heap Memory address information

? In the JVM, all thread executions (including application internal execution threads, container threads, garbage collection threads, timed threads, thread pool threads, page request forwarding threads, and more)

? Information for classes that have been loaded into the JVM

As shown in the following table:

Serial Number	Description	Example
1	? Why Java is generated ? Generation time ? The resulting thread number ? JDK version ? JVM Heap Size ? Space Heap Size ? Allocated Heap Size
2	JVM Heap Object Occupancy ratio information
3	The state of the overall thread, the proportion of the situation
4	The number of main thread types and their threads, and their proportions in the entire container
5	Other relevant information	.....

third, how to analyze Javacore.

We can provide a comprehensive analysis of the JVM through the information provided by Javacore, in addition to understanding garbage collection, JVM-related configuration information, the analysis focuses on the thread execution, analyzing which threads are waiting and which ones are executing in order to quickly narrow the scope of the problem.

(Opening the Javacore file, the huge string makes it very inconvenient for us to find information, we can use the IBM Thread and Monitor Dump Analyzer for Java tool Analysis, the tool allows us to clearly analyze the Javacore file).

In the IBM thread and Monitor Dump Analyzer for Java tool, the request thread can be divided into the following states:

? Deadlock, deadlock (focus on)

? In implementation, Runnable (focus on)

? Waiting for resources, waiting on condition (focus)

? Wait for monitor to check resources, waiting on monitor

? Pause, suspended.

? Object waiting, Object.wait ()

? Obstruction, Blocked (focus)

? Stop, parked.

Throughout the analysis process, we need to analyze the operation of the thread based on the problem (such as when the Javacore was generated, whether it was a memory overflow, or when the system was busy), and see the execution stack of the threads in different states. The analysis stack finds the code that belongs to the system application to further reduce the problem point (in the version-stable middleware, we typically start by applying code to understand which business code is triggering the problem). We want to understand the specific meaning of thread state, the stack code in the thread, the whole container of various types of threads, combined with this information for in-depth analysis.

Üdeadlock: Deadlock thread, generally refers to a number of thread calls between, into the mutual resource consumption, resulting in waiting for the situation can not be released.

Ürunnable: Generally refers to the thread is executing state, the thread is consuming resources, processing a request, it is possible to pass SQL to database execution, it is possible to manipulate a file, it is possible to convert data types, and so on.

Üwaiting on condition: Waiting for resources, if the stack information is explicitly applied code, it is proved that the thread is waiting for resources, is generally a large number of reading a resource, and the resource with a resource lock, the thread into the waiting state, waiting for the resource to read. Alternatively, you are waiting for another thread to execute.

Üblocked: Thread blocking, refers to the current thread execution, the required resources for a long time to wait has not been obtained, the container's thread manager identified as blocking state, can be understood as waiting for the resource timeout thread. This is the case in the log of was, where the CPU thirst is generally visible, or a thread has executed the information for xx seconds.

After understanding the specific meaning of the thread state, we can combine this information to further analyze the threading problem.

In the memory overflow, the analysis of the thread content in the Javacore file can be based on the Bottom-up analysis method. First look at how many threads have been set to blocked state, what requests are being made, what resources are being queued for the last step in the stack, and how to classify them, find the execution thread number that these blocked threads wait for, and in Javacore, continue to find the thread, Information that analyzes its stack and status and the record of the Monitor. Typically, these threads are in the waiting on condition state, because the threads are also waiting for the resource to be delayed or the execution time is too long, further causing the other threads in the queue that need access to those resources to be set to the blocked state. Once the thread is found, we can initially narrow the problem to which business application requests are problematic, which class is with which line of code, and what the resource is waiting for. Combine this information to analyze the business code in detail, or, depending on these questions, to find the same problem with the corresponding version of the middleware in the IBM Web site, and if so, you can consider patching upgrades.

A javacore describes the operation of the JVM in a time fragment, which is relatively limited, and for further analysis and positioning, we can collect javacore of multiple time fragments, such as the Javacore interval of 30 seconds or minutes. These javacore are analyzed separately to make it clearer how the JVM is running in that time period, or the execution of blocking threads and their associated threads to pinpoint the problem.

In the whole process of performance optimization, it is a very important step to learn how to analyze Javacore. Through the section, the running of the JVM in the thread and stack analysis, can let us smooth and directional performance tuning work, and make the optimization work more simple and quick.

Then using the JCA analysis tool, I am using the jca401 version, into the DOS environment, to execute:

Java-xmx200m-jar Jca401.jar

will open the graphical interface, transfer into the Javacore file, analysis found that the cable is in the blocked state, click on the toolbar "thread Detail" icon, can see the specific thread state and detail, locate the blocked thread, view the details, This example finds that the thread blocked by a Quartzscheduler thread that has the following call stack:

And also found a lot of waiting on condition

The quartz are waiting. The basic certainty is the timer except the problem.

Finally found that the timer's configuration file has not changed, can not connect to the database, and set the timeout time is too long.