tags:

views:

144

answers:

1

We have production Tomcat (6.0.18) server which runs with the following settings:

-server -Xms7000M -Xmx7000M -Xss128k -XX:+UseFastAccessorMethods 
-XX:+HeapDumpOnOutOfMemoryError -Dcom.sun.management.jmxremote.port=7009 
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false -verbose:gc -XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=/opt/apache-tomcat-6.0.18/conf/logging.properties 
-agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=n 
-Djava.endorsed.dirs=/opt/apache-tomcat-6.0.18/endorsed 
-classpath :/opt/apache-tomcat-6.0.18/bin/bootstrap.jar

java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode)

After some time of work we get (via JConsole) the following memory consumption:

Current heap size: 3 034 233 kbytes
Maximum heap size: 6 504 832 kbytes
Committed memory:  6 504 832 kbytes
Pending finalization: 0 objects
Garbage collector: Name = 'PS MarkSweep', Collections = 128, Total time spent = 16 minutes
Garbage collector: Name = 'PS Scavenge', Collections = 1 791, Total time spent = 17 minutes

Operating System: Linux 2.6.26-2-amd64
Architecture: amd64
Number of processors: 2

Committed virtual memory: 9 148 856 kbytes
Total physical memory:  8 199 684 kbytes
Free physical memory:     48 060 kbytes
Total swap space: 19 800 072 kbytes
Free swap space: 15 910 212 kbytes

The question is why do we have a lot of committed virtual memory? Note that max heap size is ~7Gb (as expected since Xmx=7G).

top shows the following:

31413 root  18  -2 8970m 7.1g  39m S   90 90.3 351:17.87 java

Why does JVM need additional 2Gb! of virtual memory? Can I get non-heap memory disrtibution just like in JRockit http://blogs.oracle.com/jrockit/2009/02/why_is_my_jvm_process_larger_t.html ?

Edit 1: Perm is 36M.

+1  A: 

You might want to try to hook up a JConsole to your JVM and look at the memory allocation... Maybe your Perm space is taking this extra 2GB... Heap is only a portion of what your VM needs to be alive...

Romain
It's not that simple. Perm is 36M. JConsole is attached all the time )).
Shcheklein
I did definitely not say it was simple :P Had the application been up for long? Maybe there are leaks?
Romain
Yes, it takes several hours of work to get to this state. However, it seems quite stable (except that whole machine is overloaded). What kind of leaks do you mean? Some of native libraries?
Shcheklein
Native library, bug in the VM... This kind of things happens.
Romain
Yes it could be the problem. Do you know if there are any tools to determine such leaks except turning off application's blocks one by one? It seems JRockit's print_memusage analog would be very helpful ...
Shcheklein
One possible way to go is to use ValGrind, however, I am not 100% convinced it is "humanly" possible to make sense of its output. Depends on size ...
Romain