jconsole remote connections

jconsole (and visualvm) can be used to attach to running JVMs, to give information about CPU, threads, memory, and retrieve and change JMX values.

Local

Running jconsole on the same machine as the running JVM is easiest. It finds a list of running JVMs and allows you to connect.
JConsole comes with the JDK. To install it,

yum install java-1.6.0-openjdk-devel.x86_64

Remote

However, if your JVM is running on a remote server, it gets harder.
You have the option of

ssh -Y user@remotehost jconsole

. This however requires some X libraries to be on the remote host, and also jconsole, which isn't part of the JRE - it's part of the JDK, which might not be installed on your server.

The other alternative is to enable remote JMX connections. To do that, you must start the JVM with additional arguments.

Quick and dirty

The example below will enable remote connections with NO security at all. If you do this, ensure that the port is firewalled off so that only your host can reach it, and remove it afterwards.

The options are:

-Dcom.sun.management.jmxremote 
-Dcom.sun.management.jmxremote.port=3210 
-Dcom.sun.management.jmxremote.ssl=false 
-Dcom.sun.management.jmxremote.authenticate=false

Ensure that the port is opened up to you, and then run jconsole 1.2.3.4:3210 (where 1.2.3.4 is the IP of the remote host). This should allow you to get a better insight into what your JVM is doing.

If you can't connect

There is a gotcha though, which bites me regularly. If your hostname isn't registered in DNS, it might not allow you to connect, giving you a generic "unable to connect message". If that's the case, add the additional argument

-Djava.rmi.server.hostname=1.2.3.4

where 1.2.3.4 is the output on the server of hostname -i. If hostname -i gives you an error (hostname: Unknown host), add an entry to /etc/hosts with the server's IP, and the output of hostname.

If you still can't connect, I've noticed that even though you establish the connection on the port listed in com.sun.management.jmxremote.port (3210 in our example), a second network connection is made on a high TCP port. If you're running a default DROP/REJECT firewall, try opening up all ports (only to you!), to see if this makes a difference. I haven't seen any documentation regarding this, but I've definitely experienced it myself.

Doing it right

To set up remote JMX connections more securely, use username/password authentication, and/or SSL with client certificates. Details of the various JMX remote options can be found on the Oracle site.