How to monitor java apps without additional tools or frameworks
Especially during the loadtesting phase or during the realization of
technical prototypes, it is often useful to monitor local and remote
java applications. Java SE 5 comes already with a built-in solution. To
monitor an application you have to provide only one system
parameter: -Dcom.sun.management.jmxremote. To monitor the
Swingset demoapp you have only to invoke it in the following way:
[JAVA_HOME/demo/jfc/swingset2/]> java -Dcom.sun.management.jmxremote
SwingSet2.jar
Now you can monitor this process using jconsole,
a useful tool coming with Java 5. Especially interesting is the tab
MBeans>OperatingSystem. Here you can even access the information
about the OS. Jconsole is especially useful during the loadtest, which
can be accomplished using the jmeter - an useful and free load
generator.
What will make it better is the use of scripting languages with jconsole. Here is a sample using Groovy http://blogs.sun.com/sundararajan/date/20060801
Posted by Andres Almiray on August 29, 2006 at 08:55 AM CEST #
What will make it better is the use of scripting languages =)
Here is a sample using Groovy http://blogs.sun.com/sundararajan/date/20060801
Posted by Andres Almiray on August 29, 2006 at 08:56 AM CEST #
Almiray,
thank you....and Groovy is great!
Posted by Adam Bien on August 29, 2006 at 10:48 AM CEST #
In JDK6 it would be even more easy. There is no need to provide any command line switches (and no overhead in Runtime until jconsole is connected).
Which is very cool, since it allows to attach to production system, and even allows to perform heap dumps (and analyze them with jhat, which is also very handy).
Posted by Vladimir Sizikov on August 29, 2006 at 12:33 PM CEST #
Vladimir,
thanks. I heard about it. I wasn't sure, whether this funcionality will be shipped with Java6. I will look at jhat and perhaps write a post about it...
Posted by Adam Bien on August 29, 2006 at 11:08 PM CEST #
Hi Adam,
Here is a small HOWTO regarding the tools that help find memory leaks.
Note: Use the latest JDK 6, because it has the latest tools, with
lots of bugfixes and improvements. All the later examples assume that
JDK6's bin directory is in the PATH.
Step 1. Start the application.
Start the application as you usually do:
java -jar java_app.jar
Alternatively, you could start java with hprof agent. Java will run
slower, but the huge benefit of this approach is that the stack traces
for created objects will be available which improves memory leak
analysis greatly:
java \
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=9000 \
-Dcom.sun.management.jmxremote.authenticate=false \
-Dcom.sun.management.jmxremote.ssl=false \
-agentlib:hprof=heap=dump,file=/tmp/hprof.bin,format=b,depth=10 \
-jar java_app.jar
When the application is up, perform various actions that you think might lead
to memory leaks.
You might use jconsole from JDK 6 to see the memory consumption graph
to have a clue whether memory leak is present or not:
jconsole
It will present a dialog with a list of java apps to connect to. Find
the one with java_app.jar and connect.
For example, if you open some documents in your app, the memory
graph could rapidly go up. If closing the docs and invocation of
full garbage collection did not bring the memory back to normal level,
there is probably a leak somewhere.
Jconsole allows to invoke full GC providing nice button just for that.
Step 2. Find the application pid.
Find out the application's process id via:
jps
It will print something like:
15976 java_app.jar
7586 startup.jar
22476 Jps
12248 Main
5437 Bootstrap
In our case the pid is 15976.
Step 3. Dump the heap into file.
Dump heap into the file:
jmap -dump:format=b,file=/tmp/java_app-heap.bin 15976
We just told jmap to dump the heap into /tmp/java_app-heap.bin file,
in binary from (which is optimized to work with large heaps). The
third parameter is the pid we found in Step 2.
Alternatively, if you started java with hprof agent, you could just
use Ctrl-\ on Solaris/Linux or Ctrl-Break on Windows to dump heap into
the file, specified in hprof agent arguments.
Step 4. Visualize the heap.
Use jhat tool to visualize the heap:
jhat -J-Xmx326m /tmp/java_app-heap.bin
Jhat will parse the heap dump and start a web server at port 7000
Connect to Jhat server.
Point your browser to:
http://localhost:7000
And start investigating. :)
Jhat allows you to see what obects are present in the heap, who has
references to those objects, etc.
Here are some tips:
* Investigate _instances_, not _classes_
* Use the following URL to see the instances:
http://localhost:7000/showInstanceCounts/
* Use "Reference Chains from Rootset" (Exclude weak refs!!!) to see who's holding the instance
Thanks,
--Vladimir
Posted by Vladimir Sizikov on August 30, 2006 at 12:06 PM CEST #