views:

14383

answers:

13

I need to check CPU and memory usage for the server in java, anyone know how it could be done?

+6  A: 

This question has some good info you should find useful.

jodonnell
A: 

If you are using Tomcat, check out Lambda Probe, which lets you monitor internal and external memory consumption as well as a host of other areas.

Tim Howland
A: 

Java's Runtime object can report the JVM's memory usage. For CPU consumption you'll have to use an external utility, like Unix's top or Windows Process Manager.

moonshadow
A: 

For memory usage, the following will work,

long total = Runtime.getRuntime().totalMemory();
long used  = Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();

For CPU usage, you'll need to use an external application to measure it.

Rich Adams
A: 

JConsole is an easy way to monitor a running Java application or you can use a Profiler to get more detailed information on your application. I like using the NetBeans Profiler for this.

blahspam
+1  A: 

If you use the runtime solution scaryjeff posted (I've done that a lot), be sure to force two garbage collections first if you want fairly accurate/consistent results, otherwise it's going to be all over the place.

Bill K
+2  A: 

If you looking specifically for in JVM memory:

    Runtime runtime = Runtime.getRuntime();

    NumberFormat format = NumberFormat.getInstance();

    StringBuilder sb = new StringBuilder();
    long maxMemory = runtime.maxMemory();
    long allocatedMemory = runtime.totalMemory();
    long freeMemory = runtime.freeMemory();

    sb.append("free memory: " + format.format(freeMemory / 1024) + "<br/>");
    sb.append("allocated memory: " + format.format(allocatedMemory / 1024) + "<br/>");
    sb.append("max memory: " + format.format(maxMemory / 1024) + "<br/>");
    sb.append("total free memory: " + format.format((freeMemory + (maxMemory - allocatedMemory)) / 1024) + "<br/>");

However, these should be taken only a an estimate...

Jeremy
A: 

Check out the Runtime class; it has methods to check memory usage of the JVM (as a whole). Specifically, Runtime.getRuntime().totalMemory() will tell you the number of bytes the JVM has allocated for itself. This will probably be greater than the amount of memory actually used for allocated objects, to get that figure use Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory().

Unfortunately there is no way to check the CPU usage from within the JVM using native Java. You'll need to call out to another command or write an extension using JNI to do that.

Jason Terk
A: 

Since Java 1.5 the JDK comes with a new tool: JConsole wich can show you the CPU and memory usage of any 1.5 or later JVM. It can do charts of these parameters, export to CSV, show the number of classes loaded, the number of instances, deadlocks, threads etc...

Telcontar
A: 

The YourKit Java profiler is an excellent commercial solution. You can find further information in the docs on CPU profiling and memory profiling.

Gregg
+1  A: 

JMX, The MXBeans (ThreadMXBean, etc) provided will give you Memory and CPU usages.

Javamann
+1  A: 

If you are using the Sun JVM, and are interested in the internal memory usage of the application (how much out of the allocated memory your app is using) I prefer to turn on the JVMs built-in garbage collection logging. You simply add -verbose:gc to the startup command.

From the Sun documentation:

"The command line argument -verbose:gc prints information at every collection. Note that the format of the -verbose:gc output is subject to change between releases of the J2SE platform. For example, here is output from a large server application:

[GC 325407K->83000K(776768K), 0.2300771 secs] [GC 325816K->83372K(776768K), 0.2454258 secs] [Full GC 267628K->83769K(776768K), 1.8479984 secs]

Here we see two minor collections and one major one. The numbers before and after the arrow

325407K->83000K (in the first line)

indicate the combined size of live objects before and after garbage collection, respectively. After minor collections the count includes objects that aren't necessarily alive but can't be reclaimed, either because they are directly alive, or because they are within or referenced from the tenured generation. The number in parenthesis

(776768K)(in the first line)"

For more info see: http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html