jconsole (and visualvm) can be used to attach to running JVMs, to give information about CPU, threads, memory, and retrieve and change JMX values.
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
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 18.104.22.168:3210 (where 22.214.171.124 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=126.96.36.199where 188.8.131.52 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.