Delving deeper into Jconsole and VisualVm
Jconsole and visual VM help monitor java applications in any environment. Here are a few additional details that can help you monitor your java applications better
Jconsole and permissions:
Jconsole lists the PIDs of local java applications when you start it. But what if there are java applications that are running under a different user ? Jconsole will not display those java PIDs that do not belong to the user who started Jconsole. The JConsole FAQ lists a few troubleshooting tips to get around this problem. You can alternatively expose the Jconsole connection through a remote port using the -Dcom.sun.management.jmxremote.port property. Securing the remote JMX URL with a username and password should do the trick.
While it is great that you can profile your applications on VisualVm, some users miss some of the features provided by Jconsole such as viewing JMX beans etc. You can use the Tools -> Plugins option in VisualVm to install Jconsole / Jmx or related plugins. There is of course the option of writing a custom plugin to display more information. This article already explains how to go about writing a custom plugin.
There are some cool plugins on the way for visual VM. One of them is support for OQL syntax. The language allows you to go through objects on the heap based on a selection criteria. You can use jhat and jmap to get a feel for what the language is like. The syntax is already supported on the existing heap dump analyzers.
Switching on jconsole monitoring in production is a bad idea. The article linked on the last sentence made a performance comparison around 2006, so here is a more recent comparison running a java program which solves the FoxSequence problem (a problem at topcoder.com) 1000000 times. The overhead is highlighted by the orange area. The difference represents overhead in milli seconds.
The average overhead comes to around ~7% when calculated across several trials. The question to ask though is ’7% of what ?’. For applications that take on huge traffic, an overhead of 7% spread across millions of transactions is costly. The overhead % itself may vary for your application based on a variety of factors.
Take these factors into consideration the next time you profile / monitor java apps.