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?
You can use JConsole to connect to a running Java virtual machine, and then monitor the memory usage and thread activity. You can obtain class-loading information, plus information on the JVM and the operating system.
To connect JConsole to server process, in the Remote Process section, specify the URL service:jmx:rmi:///jndi/rmi://localhost:2047/fmq and credentials pertaining to the server. Default user name and password are admin and passwd respectively.
JConsole uses only JMX, but VisualVM uses other monitoring technologies like Jvmstat, Attach API and SA in addition to JMX. It can merge data from all those monitoring technologies in one place and the user does not need to think which technology he should use in particular situation.
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:
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....
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With