Oracle/Sun says its fine as long as you don't run it locally on production box?
http://download.oracle.com/javase/1.5.0/docs/guide/management/jconsole.html
Note: Using jconsole to monitor a local application is useful for development and prototyping, but is not recommended for production environments, because jconsole itself consumes significant system resources. Remote monitoring is recommended to isolate the jconsole application from the platform being monitored.
Have you ever enabled it in a production environment and experienced any performance impacts?
Although it is highly not recommended in a production environment, there is little to no performance implications to enabling remote jmx with no authentication or encryption via options like these:
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=9999
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.remote.ssl=false
There is a little more performance cost if you turn on SSL and mandate authentication:
-Dcom.sun.management.jmxremote.authenticate=true
-Dcom.sun.management.remote.ssl=true
-Dcom.sun.management.jmxremote.password.file=jmxremote.password
The above 2 scenarios will only start an mbean server and an RMI connector server in your production JVM. Connecting to this JVM remotely will be more expensive, but it all depends on what views you watch (e.g. GC views require all that data to be collected and transported back to the jConsole client, which is not free), as well as the operations you invoke remotely.
You can read more statistics from the following blog post:
- https://community.oracle.com/blogs/emcmanus/2006/07/21/how-much-does-it-cost-monitor-app-jconsole
you can use jconsole to remotely connect to a production server using the exposed JMX ports... however its always better to replicate the scenario in a different environment & run jconsole there....
