Is a good idea to enable jmx (lambda probe) on a production server?

Question

We are experiencing some slowdowns on our web-app deployed on a Tomcat 5.5.17 running on a Sun VM 1.5.0_06-b05 and our hosting company doesn't gives enough data to find the problem.

We are considering installing lambda probe on the production server but it requires to enable jmx (com.sun.management.jmxremote) in order to obtain memory and cpu statistics.

Does enabling jmx incur a serious performance penalty?

If we enable jmx, are we opening any security flaw? Do i need to setup secure authentication if we are only enabling local acces to jmx?

Is anyone using the same (tomcat + lambda probe) without problems on production?

UPDATE

Looking at the answers it seems that enabling JMX alone doesn't incur significant overhead to the VM. The extra work may come if the monitoring application attached to the VM, be it jConsole, lambda probe or any other, is polling with excessive dedication.

Answer 1

JMX is just a socket which waits for connections and allows external processes to access data which is collected anyway. Do the penalty is usually very low (unless you hammer the JMX server with requests, of course).

JMX allows you to get at the guts of your Java VM. There are commands to run a GC and to shut it down. That said, JMX offers a secure connection mode which uses public keys and authentication. Please read the docs for details.

Answer 2

it depends on the JMX implementation and on how expensive the stuff is you want to monitor. I now at least one JMX application, which has a relatively high memory overhead.

Answer 3

You can cross out security flaws by using secure authentication. Just keeping the JMX service ready does not incur any significant overhead and is generally a good idea. There's a benchmark here about this.

Answer 4

We are using lambda probe in production servers and we didn't see any significant overheads. I can recommend probe as reliable product ready for production using (Tomcats 5.5 and 6.0, JDK 5 and JDK 6).

Answer 5

The overhead from JMX is low and you can fix the security by úsing SSL and authentication. Set -Dcom.sun.management.jmxremote.ssl=true and -Dcom.sun.management.jmxremote.authenticate=true

See here for here for more information about setting up certificates etc.

The overhead becomes a problem when you start to instrument the code. The overhead can be substantial and the instrumentation might affect the behaviour of your application. You will not see what you get, the so called heisenberg effect.

If you want low overhead I would use the tools that come with JRockit. They piggyback on the information the JVM collects all the time. The JVM keeps statistics of which methods are the running the most to decide which methods it should optimize. The JVM also keeps track of memory usage/patterns to decide which gc-stategy to select. JRockit exposes that kind data to the JRockit tools without adding the instrumentation overhead you normally would get from a separate JMVTI-agent.