How to Check Heap Usage of a Running Jvm from the Command Line

How to check heap usage of a running JVM from the command line?

You can use jstat, like :

 jstat -gc pid

Full docs here :
http://docs.oracle.com/javase/7/docs/technotes/tools/share/jstat.html

Getting total used memory of a running JVM under Linux

You can run

ps aux | grep java

This will show you the memory usage of each application containing java in their launch-string, which should be most if not all java apps.

The output from my server is the following:

servername:~ servername$ ps aux | grep java
servername 50122   0.3  1.7  2832968  89236   ??  S    Thu08AM 117:55.94 /usr/bin/java -jar /srv/eurekaj/Proxy/eurekaJ.Proxy-1.0.RC1-jar-with-dependencies.jar
servername 72399   0.0 25.9  4978676 1355616   ??  S    29Jul11 1560:43.70 /usr/bin/java -Xmx2g -Xms1g -Djava.io.tmpdir=/tmp -Dbtrace.agent=HudsonAgent -javaagent:/srv/btrace/1.2/btrace-agent.jar=scriptdir=/srv/btrace/scripts,stdout=false,fileRollMilliseconds=7500 -jar hudson.war --httpPort=8093
servername 72392   0.0  8.3  3169604 437192   ??  S    29Jul11 120:41.42 /usr/bin/java -Xmx256m -Xms256m -Djava.io.tmpdir=/jettytmp -Dbtrace.agent=JSFlotDemoAgent -Dlog4j.configuration=file:/srv/jsflot/demo/log4j.xml -javaagent:/srv/btrace/1.2/btrace-agent.jar=scriptdir=/srv/btrace/scripts,stdout=false,fileRollMilliseconds=7500 -classpath :very_verbose_classpath org.jsflot.server.JettyServer
servername 97501   0.0  0.0  2425712    276 s000  R+    4:58AM   0:00.00 grep java

What you can read from this is PID, CPU Usage (%) and Memory Usage (%) for each of the processes.

You can also use the

top

command to get similar results.

Get Max Heap Size of Running JVM from Command Line: No JDK Tools

After much trial and error, I came upon the following solution. It does use the assumption that the JVM process with the biggest Xmx value is the one of interest.

DATA_UNIT_MULTIPLIER=1024
XMX_JVM_VALUE=$(ps -ef | grep -oP "Xmx\d+(m|g)" | sort -rn | cut -d'x' -f2 | head -1)
XMX_DATA_UNIT="${XMX_JVM_VALUE:$((${#XMX_JVM_VALUE}-1)):1}"
XMX_JVM_NUM=$(echo $XMX_JVM_VALUE | sed '$s/.$//')

XMX_SIZE=1
if [ "$XMX_DATA_UNIT" = "m" ]; then
    XMX_SIZE=$(($XMX_JVM_NUM * $DATA_UNIT_MULTIPLIER ))
elif [ "$XMX_DATA_UNIT" = "g" ]; then
    XMX_SIZE=$(($XMX_JVM_NUM * $DATA_UNIT_MULTIPLIER * $DATA_UNIT_MULTIPLIER))
fi

This implementation converts the value of Xmx into the same units being reported by df. It also take into consideration the unit suffix on the Xmx option.

How to identify default Java heapsize in Windows

You can use -XX:+PrintFlagsFinal to print out a huge list of internal options to the JVM once all command line arguments and defaults have been processed. The -Xms option corresponds to InitialHeapSize, and the -Xmx option corresponds to MaxHeapSize.

To find the default maximum heap size that the JVM is using on Windows, run:

javaw -XX:+PrintFlagsFinal | find "MaxHeapSize"

To find the default initial heap size, run:

javaw -XX:+PrintFlagsFinal | find "InitialHeapSize"

How to view the current heap size that an application is using?

Use this code:

// Get current size of heap in bytes
long heapSize = Runtime.getRuntime().totalMemory(); 

// Get maximum size of heap in bytes. The heap cannot grow beyond this size.// Any attempt will result in an OutOfMemoryException.
long heapMaxSize = Runtime.getRuntime().maxMemory();

 // Get amount of free memory within the heap in bytes. This size will increase // after garbage collection and decrease as new objects are created.
long heapFreeSize = Runtime.getRuntime().freeMemory(); 

It was useful to me to know it.

Jstat and Jvisualvm show different numbers for heap usage/allocation

It turns out that adding up the EU and OU columns of jstat is approximately equal to the heap usage shown in jvisualvm. The EU+OU is always about 12 MB less than what's shown in jvisualvm for the process that I am monitoring. (In the example I provided in my question, jvisualvm is showing 506 MB of heap usage and jstat shows EU+OU = 240 MB. So I must have run jstat right after the heap usage dropped back down to 250 MB.)

Adding up the EC and OC columns of jstat is approximately equal to the heap allocation shown in jvisualvm. The EC+OC is about 45-60 MB less than what's shown in jvisualvm for the process that I am monitoring.

Find the heapsize in JRE

You are looking for the current memory usage of your running process? Have you tried the following?

Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory()

Monitor non-heap memory usage of a JVM

Your heap is actually using 6.5 GB of virtual memory (this may include the perm gen)

You have a bunch of threads using 64 MB stacks. Not clear why some are and others are using the default 1 MB.

The total is 9.3 million KB of virtual memory. I would only worry about the resident size.

Try using top to find the resident size of the process.

You may find this program useful

    BufferedReader br = new BufferedReader(new FileReader("C:/dev/gistfile1.txt"));
    long total = 0;
    for(String line; (line = br.readLine())!= null;) {
        String[] parts = line.split("[- ]");
        long start = new BigInteger(parts[0], 16).longValue();
        long end = new BigInteger(parts[1], 16).longValue();
        long size = end - start + 1;
        if (size > 1000000)
            System.out.printf("%,d : %s%n", size, line);
        total += size;
    }
    System.out.println("total: " + total/1024);

---

Unless you have a JNI library using the memory, my guess is you have lots of threads which each have their own stack space. I would check the number of threads you have. You can reduce the maximum stack space per thread, but a better option might be to reduce the number of threads you have.

The off heap memory is by definition unmanaged, so it is not easily "tuned" as such. Even tuning the heap is not simple.

The default stack size on 64-bit JVMs is 1024K so 700 threads will be using 700 MB of virtual memory.

You shouldn't confuse virtual memory sizes for resident memory sizes. Virtual memory on a 64-bit application is almost free and it's only the resident size you should worry about.

The way I see it you have 9.3 GB total.

• 6.0 GB heap.
• 128 MB perm gen
• 700 MB stacks.
• < 250 shared libraries
• 2.2 GB of unknown (I suspect virtual memory not resident memory)

The last time some one had this problem they had a lot more threads than they though they should. I would check the maximum number of threads you had as it is the peak which determines the virtual size. e.g. was it closer to 3000?

---

Hmmm each of these pairs is a thread.

7f0cffddf000-7f0cffedd000 rw-p 00000000 00:00 0 
7f0cffedd000-7f0cffee0000 ---p 00000000 00:00 0

and these suggest you have slightly less than 700 threads now.....

---

Related Topics