Java Performance Analysis Artifact-jprofiler detailed

Some time ago in the performance analysis of the company's projects, from a simple analysis of log (GC log, postgrep log, Hibernate statitistic), through the AOP to collect software running data, to pet testing, feel time spent a lot, performance also has a certain increase, But it always feels like working in primitive times, unable to be simple and smooth, and to achieve the desired result with great clarity. It took a while to learn from the new comb the various tools that have been used before about JVM tuning and memory analysis, including the JDK's JPS, Jstack, Jmap, Jconsole, and IBM Heapanalyzer, which offer a number of features But its usability, ease of use, far from the IntelliJ to Java development that point. In the occasional case, in the cloud habitat found someone recommended Jprofiler, installed on the use of a version, found to be an artifact, it is hereby recommended to you. First of all, this software is commercial, online has a lot of lisence on the post, I forwarded here, but never recommend you use cracked version!

[Email protected] #36573-fdkscp15axjj6#25257
[Email protected] #5481-ucjn4a16rvd98#6038
[Email protected] #99016-hli5ay1ylizjj#27215
[Email protected] #40775 -3wle0g1uin5c1#0674
[Email protected] #7009 -14frku31ynzpfr#20176
[Email protected] #49604 -1jfe58we9gyb6#5814
[Email protected] #25531 -1qcev4yintqkj#23927
[Email protected] #96496 -1qsu1lb1jz7g8w#23479
[Email protected] #20948 -11amlvg181cw0p#171159

Then, first turn to a cloud-dwelling article, and then slowly start our jprofiler journey.

I. What is Jprofiler?

Jprofiler is a performance bottleneck analysis tool developed by Ej-technologies GmbH (the company also develops deployment tools).
Its characteristics:

• Easy to use
• Friendly interface operation
• Small impact on the application being analyzed
• Cpu,thread,memory analysis features are especially powerful
• Support for analysis of Jdbc,nosql, JSP, servlet, socket, etc.
• Support for analysis of multiple modes (offline, online)
• Cross-platform (figure 1)

Two. Data acquisition

Q1. Jprofiler since it is a performance bottleneck analysis tool, where are the relevant data for these analyses coming from?
Q2. How does Jprofiler collect and present these data?

(Fig. 2)

A1. The analysis of the data is mainly from the following two parts
1. Part of the Analysis interface **jvmti** (JVM Tool Interface) from the JVM, the JDK must be >=1.6

JVMTI is an event-based system. The Profiling Agent library can register handler functions for different events. It can then enable or disable selected events

For example: The life cycle of an object, the life cycle of thread, etc.
2. Part from instruments classes (can be understood as class rewrite, add Jprofiler related statistics function)
Example: Method execution time, number of times, method stack and other information

A2. Principles of data Collection 2
1. User commands for monitoring in the Jprofiler GUI (usually click a button)
2. The Jprofiler GUI JVM sends instructions to the Jprofile Agent in the analyzed JVM via the socket (default port 8849).
3. Jprofiler Agent (if you do not know the agent please see the third part of the "startup mode") after receiving the instruction, the instruction will be converted to the relevant event or instruction to listen, to register to the JVMTI or directly let JVMTI to perform a function (such as dump JVM memory)
4. JVMTI collects information about the current JVM based on registered events. For example: The life cycle of a thread; The life cycle of the JVM, the life cycle of the classes, the life cycle of the object instance, the real-time information of heap memory, etc.
5. Jprofiler Agent to save the collected information to * * in memory * *, according to a certain rule statistics (if all data sent Jprofiler GUI, will be the analysis of the application network has a relatively large impact)
6. Return to the Jprofiler GUI Socket.
7. Jprofiler GUI Socket will receive the information returned Jprofiler GUI Render
8. Jprofiler GUI render render as final display effect

Three. Data acquisition method and startup mode

A1. Jprofier collection methods are divided into two types: sampling (sample collection) and instrumentation

• Sampling: Similar to sample statistics, the information in each line stacks method stack is counted at a certain time (5ms). The advantage is that the impact on the application is small (even if you do not configure any filter, filter can refer to article fourth), the disadvantage is that some data/features are not available (e.g., number of calls to the method)

• Instrumentation: Before class is loaded, Jprofier writes the relevant function code to the class that needs to be parsed, which has an impact on the running JVM. Pros: Powerful, but if you need to analyze more than the class, then the impact on the application is large, generally with the filter used together. So the general JRE class and the framework class are usually filtered out in the filter.

Note: The jprofiler itself does not indicate the type of data collection, where the collection type is the acquisition type for the method call. Because most of the core functions of jprofiler depend on the data collected by the method call, it can be considered as the Jprofiler data acquisition type directly.

A2: Boot mode:

• Attach mode
  Loads the Jprofiler Agent directly into the JVM that is running natively. The advantages are very convenient, the disadvantage is that some features can not be supported. If you choose the instrumentation data acquisition method, it takes some extra time to rewrite the class that needs to be analyzed.

• Profile at startup
  manually loads the specified Jprofiler agent into the JVM when it is started by the parsed JVM. The Jprofiler GUI sends configuration information, such as information types and policies, to the Jprofiler Agent via a socket, which is not started until it receives this information. The
  adds the following to the startup parameters of the JVM being parsed:
  Syntax:-agentpath:[path to Jprofilerti Library]
  Note: The syntax is not clear okay, Jprofiler provides a Help wizard.
  
  (Figure 3)

• Prepare for profiling: The main difference between
  and profile at startup: The JVM being analyzed does not need to receive the relevant configuration information for the Jprofiler GUI to start.

• Offline profiling
  is typically used for scenes that cannot be debugged directly on a line. Offline profiling need to collect information and policies (some trigger, trigger please refer to article fifth) packaged into a configuration file (config. ins), when the JVM is launched online to load the Jprofiler agent, Load the XML. Then the Jprofiler agent will generate different information depending on the type of trigger. For example: Heap dump; Thread dump; Method call record, etc.
  Syntax:
  -agentpath:/home/2080/jprofiler8/bin/linux-x64/libjprofilerti.so=offline,id=151, Config=/home/2080/config.xml
  Note: The collection information for each of the analyzed JVM in config. * is identified by an ID.
  The following offline mode is used and the trigger of the dump heap is used every second:
  

Four. Jprofiler Core concept

1. Filter: What class needs to be analyzed. is divided into a filter that contains and does not contain two types.
   
   (Fig. 4)

2. Profiling Settings: Strategies for Receipt collection: Sampling and instrumentation, some data acquisition details can be customized.
   
   (Fig. 5)

3. Triggers: Generally used in **offline** mode, tells the Jprofiler Agent when to trigger what behavior to collect the specified information.
   
   (Fig. 6)

4. Information about the Live Memory:class/class instance. For example, the number of objects, size, object creation method execution stack, object creation hotspot.
   
   (Fig. 7)

5. Heap Walker: Perform static analysis of information collected for a certain amount of time, in a powerful and used way. Outgoing reference containing objects, incoming reference, biggest object, etc.
   
   (Fig. 8)

6. The distribution and time of CPU VIEWS:CPU consumption (CPU time or running time); The execution diagram of the method; Execution statistics of the method (maximum, minimum, average run time, etc.)
   
   (Fig. 9)

7. Thread: The running state of all threads of the current JVM, the thread holds the state of the lock, can dump the thread.
   
   (Fig. 10)

8. Monitors & Locks: All threads hold locks and lock information
   
   (Fig. 11)

9. Telemetries: A trend graph with heap, thread, GC, class, etc. (telemetry view)

Five. Practice

In order to facilitate the practice, a direct example of JProfiler8 to help understand the above related concepts.
Examples of Jprofiler are as follows: simulations of memory leaks and thread blocking scenarios:
Specific source code reference:/jprofiler Install Path/demo/bezier

(Fig. 12)

(Fig. Leak memory simulates the leak, simulate blocking to simulate the blocking of the lock between threads)

A1. First to analyze the scenario of a memory leak: (tick the Leak memory in Figure 13 to simulate the leak)
1. In the **telemetries-> memory** view you will see roughly the same scenario (which can be performed in the process of the run GC for a period of time): see the Blue area, the size of the Laosheng generation after the GC (* * trough) is slowly increasing (ideally , this value should be stable)

(Fig. 14)

1. Click the **record allocation data** button in Live memory->recorded Objects to start counting the object information created over time. After performing a **run gc**, look at the size of the current object information and click the **mark current** button in the toolbar (in fact, to mark the current number of objects. Execute the Run GC once, then continue with the observation, execute a run GC, and then continue to observe .... Finally, see which objects continue to rise after the GC. Finally the information you see May and similar
   
   (Figure 15 Green is the number before the mark, and Red is the increment after the mark)

2. Analyze the object information you just recorded in the heap Walker
   
   (Fig. 16)
   
   (Fig. 17)

3. Click the class with the most instances, right-**use Selected instances->reference->incoming reference**.
   found that the long data is eventually stored in **bezier. The beaieranim.leakmap**.
   
   (Fig. 18)

In the Allocations tab, right-click on one of the methods to see the specific source information.

(Fig. 19)

"Note": To here the problem is very clear, understand in Figure 17 why the number of instances is the same, and why the existence of FULLGC after or not recycled (an old area of the object leakmap,put information will also enter the old area, leakmap, such as recovery can not be lost, Then the objects contained in the map are not recycled.

A2. Simulate a thread-blocking scenario (tick Figure 13 simulate blocking to simulate the blocking of a lock between threads)
To facilitate the separation of threads, I named the Bezieranim.java L236 thread in the demo as test

public void start() {            thread = new Thread(this, "test"); thread.setPriority(Thread.MIN_PRIORITY); thread.start(); }

Under normal circumstances, such as

(Fig. 20)

Check the "Simulate blocking" option in the demo, such as (note the status icon below), the test thread block state significantly increased.

(Fig. 21)

After observing the **monitors & Locks->monitor history** for a period of time, there are 4 types of locks that occur.

The first type:
The awt-eventqueue-0 thread holds a lock on an object and is in the waiting state.

The code at the bottom of the figure suggests that the Demo.block method called the Object.wait method. This is still relatively easy to understand.

(Fig. 22)

The second type:
The awt-eventqueue-0 occupies the lock on the Bezier.bezieranim$demo instance, and the test thread waits for the thread to release.

Note The source code below, this lock occurs because the Blcok method of the demo is in the AWT and test thread
will be executed, and the method is synchronized.

(Fig. 23)

The third and fourth types:
The test thread continually submits the task to the event dispatching thread, resulting in a competing Java.awt.EventQueue object lock.
The way to submit the task is the following code: repaint() andEventQueue.invokeLater

        public void Run() {Thread me = Thread.CurrentThread (); while (thread = = Me) {repaint (); if (block) {block (false);} try {thread.sleep (10);} catch (Exception e) {break ;} Eventqueue.invokelater (new Runnable () { @Override public void Run() {Onedtmethod ();}}); thread = null;}                 

(Fig. 24)

Six. Best practices

1. Jprofiler will give tips on some special operations, so it's best to read the instructions carefully.
2. The "Mark current" feature works well in some scenarios
3. The heap walker is typically static analysis of object information in live Memory->recorder objects, which may be recycled by GC, causing nothing in the heap walker to appear. This behavior is normal.
4. You can only configure the information collected once in the toolbar in Start recordings
5. The include and exclude in the Filter are sequential, and note that the order is validated using the * * Show Filter Tree * * * * * * * in the lower left * * (Figure 25)

Seven. References

1. Jprofiler helper:http://resources.ej-technologies.com/jprofiler/help/doc/index.html

2. Jvmti:http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html

Java Performance Analysis Artifact-jprofiler detailed (GO)