From Xuwanbest blog 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 above information, it can be very helpful for system tuning. 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 situation, you can choose to open the monitoring item, not all open. 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. , 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) personal opinion is the number of objects 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 "take the heap Snapshot for Selection", select the completion 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. Jprofiler monitoring may have a certain time difference between applications, so there are times when you need to wait for a refresh to display the correct system condition.
Windows
the client's Jprofiler remotely monitors the Tomcat on Linux
1. Test environmentServer: 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/jprofiler1. # Cd/opt/jprofiler2. # chmod +x *.sh3. #./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 here, the-C means to install in character mode, if there is no X on the machine add this parameter.
5. Client Connection Configuration1). Run Jprofiler. The first time you open a wizard, ignore it. 2). Select Session->integration wizard->new Remote Integratation3). Select on a remote computer;platform of remote computer select Linux x86/amd 64;next4). Enter the server IP; Next5). Enter the installation path for the Jprofiler on the server, such as/opt/jprofiler4; next6). Select the server's JDK environment, this is: SUN,1.5.0,HOTSPOT;NEXT7). Input port: Here is the default value 8849;next8). Select the startup mode: Here is the first wait for a connection from the Jprofiler Gui;next9). 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 Theremot E application that's started with the modified Start command.
6. Server-side configuration(1) Modify the system environment configuration file/etc/profile, add 1. Jprofiler_home=/opt/jprofiler4/bin/linux-x86 2. Export ld_library_path= $LD _library_path: $JPROFILER _home (2) Modify the Tomcat boot file catalina.sh, add-agentlib:jprofilerti=port= 8849-xbootclasspath/a:/opt/jprofiler4/bin/agent.jar content into 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 would show:1. Jprofiler
>Protocol version 23 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 softwareClick Jprofiler Menu Session>start center>open sessionavailable Session Configurations list the connection you just configured, check use 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 interruptedThe log of Tomcat which is $CATALINA _home/logs/catalina.out would show:1. Jprofiler
>Disconnected. Waiting for reconnection. 2. Jprofiler
>Listening on port:8849.
Reprinted: Jprofiler Remote monitoring of the Tomcat process on Linux
