Jprofiler Trial Notes

The Jprofiler is a Java performance monitoring tool. You can view currently applied objects, object references, memory, CPU usage, threads, thread runs (blocking, waiting, and so on) while looking for application memory hotspots, here are a few articles for reference: getting, introducing, getting started, using Jprofiler to solve real-world problems. This article basically introduces the common things, the following to say a bit of experience.

Ad:51cto College: It quality courses online look!

The so-called "工欲善其事, its prerequisite", good tools can play the role of half-times. The most I have used is two jconsole and Jprofiler. Jconsole monitors system memory changes, and if there is a memory overflow, garbage collection will appear jagged. After discovering the problem, use Jprofiler to monitor the object changes under small pressure (or no pressure) and locate the cause of memory overflow.

The Jprofiler is a Java performance monitoring tool. You can view currently applied objects, object references, memory, CPU usage, threads, thread runs (blocking, waiting, and so on), and you can look for hot spots where the application memory is used, that is, which object consumes more memory, or CPU hotspots, that is, where the method occupies a larger CPU resource. I use 4.3.2 version, previously tried 3** version, but the bug is more, easy to die, 4** version is more stable.

With the information above, the system tuning will be very helpful. Here are a few articles for your reference: getting, introducing, getting started, using Jprofiler to solve real-world problems. This article basically introduces the common things, the following to say a bit of experience.

1. Jprofiler monitoring is to consume system resources, so generally do not use for performance testing time monitoring.
2. If you want to use a relatively large pressure case, you can have the option to open the monitor item without all opening. There are two main, one is memory monitoring, open the case can find memory allocation hotspot. One is CPU monitoring, in which case you can view CPU usage hotspots.

, the Red Pen callout section. If the two are closed, you can still run a certain amount of pressure, but also can monitor the number of objects.

1. The most useful (and most used) person considers the number of objects that are currently being queried. Quantity monitoring is important, if you use a singleton, then you will only see an object exists, if more than the program has a problem. Similarly, if the application does a series of actions, check to see if the destroyed object continues to exist, and if not released, consider whether there is a memory overflow.
2. Jprofiler also provides a good tool to check for memory overflow. He can look up a reference to an object, that is, when you find that the released object is not released, you can see which instance is referencing it and find the overflow point by finding the root.
3. The operation is as follows: in the "Memory views" screen right-click on the object you want to monitor, select the first item "Take the heap Snapshot for Selection", the selection is completed will enter the "Heap Walker" interface, below the interface provides several functions, select " References "can.

4. Jprofiler provides different viewing granularity, provides monitoring of the class, monitoring of the package, monitoring of the Java EE components, and the filter is also relatively useful, directly locating the package or class you are interested in.
5. There may be a time difference between the Jprofiler monitoring and the application, so there are times when you need to wait for the refresh to show the correct system condition.

Windows Client Jprofiler remotely monitor Tomcat on Linux

1. Test environment

Server: RedHat Linux 3.4.3-9.el4 (kernel version 2.6.9-5.el), Tomcat5.5.20,sun JDK 1.5.0_09,jprofiler 4.3.2 for Linux (installation package: Jprofiler_ linux_4_3_2.sh)

Client: Windows Xp,jprofiler 4.3.2 for Windows (Installation package: Jprofiler_windows_4_3_2.exe)

2.JProfiler Software http://www.ej-technologies.com/

3. Client Jprofiler installed slightly

4. Server-side Jprofiler installation:

Upload the jprofiler_linux_4.3.2.sh to the server, assuming the path is/opt/jprofiler

1. # Cd/opt/jprofiler
2. # chmod +x *.sh
3. #./jprofiler_linux_4.3.2.sh-c

Follow the prompts to install, the tips are very simple, not much to say. Installation path Selection/opt/jprofiler4

Note that the-C meaning here is installed in character mode, if there is no X on the machine add this parameter.

5. Client Connection Configuration

1). Run Jprofiler. The first time you open a wizard, ignore it.

2). Select Session->integration wizard->new Remote integratation

3). Select on a remote computer;platform of remote computer select Linux X86/AMD 64;next

4). Enter the server IP; Next

5). Enter the installation path for the Jprofiler on the server, such as/opt/jprofiler4; next

6). Select the server's JDK environment, this is: Sun,1.5.0,hotspot;next

7). Input port: Here is the default value 8849;next

8). Select the startup mode: Here is the first wait for a connection from the Jprofiler Gui;next

9). The configuration that needs to be done on the server side is listed here:

1. Integration type: [Generic application]
2. Selected Jvm:sun 1.5.0 (hotspot)
3. Startup mode:wait for Jprofiler GUI

(1) Please insert

-agentlib:jprofilerti=port=8849-xbootclasspath/a:/opt/jprofiler4/bin/agent.jar

Into the start command of your remotes application right after the Java command.

(2) Please add

/opt/jprofiler4/bin/linux-x86

To the environment variable Ld_library_path.

A remote session named remote application on 192.168.40.15 would be is created that connects to a running instance of the Remo TE application that's started with the modified Start command.

6. Server-side configuration

(1) Modify the system environment configuration file/etc/profile, increase

1. Jprofiler_home=/opt/jprofiler4/bin/linux-x86
2. Export ld_library_path= $LD _library_path: $JPROFILER _home

(2) Modify Tomcat boot file catalina.sh, add-agentlib:jprofilerti=port=8849-xbootclasspath/a:/opt/jprofiler4/bin/agent.jar Content into the catalina_opts;

"-agentlib:jprofilerti=port=8849-xbootclasspath/a:/opt/jprofiler4/bin/agent.jar" This content is generated by the client software

catalina_opts= "$CATALINA _opts-xms128m-xmx128m $JPDA _opts-agentlib:jprofilerti=port=8849-xbootclasspath/a:/opt/ Jprofiler4/bin/agent.jar "

7.Reboot Linux and startup Tomcat using Startup.sh;

The log of Tomcat which is $CATALINA _home/logs/catalina.out'll show:

1. Jprofiler> Protocol version
2. Jprofiler> Using JVMTI
3. Jprofiler> 32-bit Library
4. Jprofiler> Listening on port:8849.
5. Jprofiler> Native library initialized
6. Jprofiler> waiting for a connection from the Jprofiler GUI

8. Start the Client software

Click Jprofiler Menu Session>start center>open session

Available session configurations is listed in the connection just configured, check the use of OK!!

9.The log of Tomcat which is $CATALINA _home/logs/catalina.out'll show:

1. Jprofiler> Using Dynamic Instrumentation
2. Jprofiler> Time measurement:elapsed time
3. Jprofiler> CPU profiling enabled
4. Jprofiler> Hotspot compiler enabled
5. Jprofiler> Starting org/apache/catalina/startup/bootstrap

10. When the Jprofiler connection is interrupted

The log of Tomcat which is $CATALINA _home/logs/catalina.out'll show:

1. Jprofiler> disconnected.  Waiting for reconnection.
2. Jprofiler> Listening on port:8849.

(EXT) Jprofiler Trial notes