Heapsize and other memory configuration of java on Tomcat 7 container of Red Hat

Question

I'm using a Red Hat tomcat7 container (very similar as the tomcat7 on docker hub):

registry.access.redhat.com/jboss-webserver-3/webserver30-tomcat7-openshift:1.2-12

I've deployed some .wars in it but after performing a lot of process I got the following error:

GC overhead limit exceeded
java.lang.OutOfMemoryError: GC overhead limit exceeded

So I want to investigate the max heapsize and the other memory settings:

Command:

java -XX:+PrintFlagsFinal -version | grep -iE 'HeapSize|PermSize|ThreadStackSize'
Output:
Picked up JAVA_TOOL_OPTIONS: -Duser.home=/home/jboss -Duser.name=jboss          
     intx CompilerThreadStackSize                   = 0                         
          {pd product}                                                          
    uintx ErgoHeapSizeLimit                         = 0                         
          {product}                                                             
    uintx HeapSizePerGCThread                       = 87241520                  
          {product}                                                             
    uintx InitialHeapSize                          = 125829120                 
          {product}                                                             
    uintx LargePageHeapSizeThreshold                = 134217728                 
          {product}                                                             
    uintx MaxHeapSize                               = 1983905792             
          {product}                                                             
     intx ThreadStackSize                           = 1024                      
          {pd product}                                                          
     intx VMThreadStackSize                         = 1024                      
          {pd product}                                                          
openjdk version "1.8.0_91"                                                      
OpenJDK Runtime Environment (build 1.8.0_91-b14)                                
OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)

I don't know how I have to interpret this information. I thought about increasing the heapsize.

What is the meaning of pd product or product?
Is the max heapsize = the max memory consumption of java or of your application or of your whole tomcat? Because after some investigation I saw the container was using a lot more memory than 1892 MB (19839...) when it had the outofmemory issue.

score 2 · Accepted Answer · edited May 23 '17 at 11:59

Tomcat should use a single JVM for all application. This is indeed using 1892 MB ( 1983905792 B / 1024² ), the issue here might be:

You have a memory leak - you are keeping references to objects your are using and they are causing your VM cannot free memory with garbage collection. Explained much better here. Try figuring out why this is happening by looking at the output of jmap -histo <javaPID>
Your app is functioning normally, and you indeed need more heap memory. You can increase the memory by setting set CATALINA_OPTS= -Xmx2g

score 0 · Answer 2 · answered May 05 '16 at 17:44

Although your questions don't really address your problem, as @Razvan did:

What is the meaning of pd product or product? [in PrintFlagsFinal]

It means the flag is usable in 'product' (released) builds as opposed to those for developmental, QA, diagnostic or experimental use. 'pd' means platform dependent (Solaris vs Linux vs Windows etc).

Is the max heapsize = the max memory consumption of java or of your application or of your whole tomcat? Because after some investigation I saw the container was using a lot more memory than 1892 MB (19839...) when it had the outofmemory issue.

The running Java process uses memory for lots of things other than the heap. You can see this with /proc/$pid/maps on Linux, or jmap (in default format) if you have full JDK installed on any OS:

code for the JVM itself, including the interpreter and JIT compiler HotSpot, and various libraries, plus any 'native' code accessed via JNI or JNA, and 'native' data. In general code may be shared with other processes, but I'm not sure if this remains true in a docker container.
'Metaspace' (in Java 8, 'PermGen' in earlier versions) and 'CodeCache' which contain loaded classes and JITted code for them
thread stacks; Tomcat uses quite a few threads, and even if the Java code doesn't, JVM has some builtin threads and maybe native threads as well
'direct' NIO buffers if used (and I think Tomcat can at least sometimes)

But only objects in the heap are garbage collected, so other areas are irrelevant to GC failure.

Also I'm not sure if docker memory measurement includes anything beyond the process itself. You might compare to top or ps -F.

Heapsize and other memory configuration of java on Tomcat 7 container of Red Hat

2 Answers2