tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neven Cvetkovic <>
Subject Re: RE : Tomcat 6.0.35 Crashed again
Date Thu, 11 Apr 2013 13:56:19 GMT

On Thu, Apr 11, 2013 at 1:09 AM, saumil shah <> wrote:

> Hello All,
> We are using Tomcat 6.0.35 for our production system with 64 bit JVM
> (1.6.33) on Windows 2008 R2 SP1. Our physical memory is 24gb. Load is ~ 100
> concurrent sessions.
> The Tomcat crashed again with OutOfMemoryError: Java heap space error. We
> are using COTS product SAP Business Objects. Upon providing Tomcat logs ,
>  SAP came with recommendation of increasing the heap size . Our current
> Java params are :
> -Xms512m -Xmx1024m
> -XX:MaxPermSize=512m
> SAP's recommendation is to make it ...
> -Xms1024m -Xmx4096m

We have ample of free memory on the box ...
> 1a. but the question was heap size as Max 4GB , would it cause application
> delay when java GC is due? It's NOT time-sensitive application.1b. Also,
> when putting MAx as 4GB , does it mean JVM will make base effort to get 4GB
> MAX memory for heap , or is that guaranteed? Based on my reading, it
> appeared that only Min, was guaranteed.1c. Is it then recommended to have
> Min and Max as 4GB ... so that Heap doesn't have to resize and 4GB is
> guaranteed at the time of initialization?1d. I have Tomcat service
> installer..... I have provided Min and Max heap size values under Tomcat
> --> Java tab --> Initial Memory Pool and Maximum memory pool ...... I am
> assuming that means Min and Max values for this correct?

You are correct. When starting JVM you are providing JVM parameters as part
of the command line.  Usually, we define that in some script (Tomcat's best
way is to place these in setenv.bat).

-Xms represents initial heap size
-Xmx represents the maximum size heap can grow to

Now, you might see JVM process takes more memory than Xmx value, because
JVM needs to allocate memory not only for heap, but some other things as
well, e.g. stack for each thread (-Xss value). If the stack is too small
you would get StackOverflowError, if you have lot of threads (and stack is
fairly large) you will run out of memory. Now, I don't think that's your
case. You have 24G on the machine.

Read more about JVM tuning here:

"...Large server applications often experience two problems with these
defaults. One is slow startup, because the initial heap is small and must
be resized over many major collections. A more pressing problem is that the
default maximum heap size is unreasonably small for most server
applications. The rules of thumb for server applications are:
- Unless you have problems with pauses, try granting as much memory as
possible to the virtual machine. The default size (64MB) is often too small.
- Setting -Xms and -Xmx to the same value increases predictability by
removing the most important sizing decision from the virtual machine.
However, the virtual machine is then unable to compensate if you make a
poor choice.
- In general, increase the memory as you increase the number of processors,
since allocation can be parallelized."

Of course, it really comes down the application memory usage. How is your
application written? How does it behave under heavy load? How are your
objects being created, how many, how often, how big? How do you setup GC,
what heuristics/strategies did you setup, etc...

Often times, you would see people set -Xmx and -Xms to the same value (e.g.
4G) this is to reduce the resizing of the initial heap multiple times as
your heap consumption grows. However, setting the heap size too big, your
GC has much more memory to manage, which makes the GC overhead impact the
performance of the application...

There is no cookie-cutter solution that fits all. JVM optimization is
trial-and-error process. One is sure - you have to have a good testing
environment where you can reasonably reproduce loads your application
usually gets (heavy load, light load, etc...)

(Where are you setting these values Xmx and Xms btw?)

2. When trying to monitor Tomcat , using JConsole and VisualVM ..... do I
> need to add JMX agent and port ....  in Java tab of Tomcat and then restart
> , or is it possible to Monitor tomcat , without rebooting it ? Since, it
> would not be possible to re-boot tomcat in production for it.

Short answer is no. If you can login into the machine where Tomcat runs,
you can run jconsole/jvisualvm locally and there is no need to open JMX
management ports. However, if you want to connect to remote JVM processes
(ie. JVM running on remote machines, e.g. production JVMs) you need to open
up the JMX management ports using appropriate switches (again, these are
set setenv.bat)

More details here:

3. Once JConsole and/or VisualVM is setup ... I can look at Heap/Permgen ,
> memory , threads etc...... I was wondering how do I see memory leaks and
> what is causing it , using these tools?

Memory leak is situation when the objects keep getting stuck in memory
unnecessary. You can't really detect these things without understanding
your application code. There is a useful utility for mapping the heap, take
a look at JMAP ( The
idea is that you need to spot upward trends over time, and noticing that
some objects are not being garbage collected. Also, there are plenty of
commercial profilers that can help you detect memory leaks.

Here's an example of using JProfiler to detect memory leaks.

> 4. Also, I am seeing that Tomcat is deploying the webapps on start-up ....
> is there anyway to avoid Tomcat to deploy the application on
> the applications are already deployed and exploded? Example is below :Apr
> 5, 2013 7:17:27 PM org.apache.catalina.startup.HostConfig deployWARINFO:
> Deploying web application archive AnalyticalReporting.warApr 5, 2013
> 7:17:28 PM org.apache.catalina.core.StandardContext
> addApplicationListenerINFO: The listener
> "com.sun.faces.config.ConfigureListener" is already configured for this
> context. The duplicate definition has been ignored.
This is not a notice that application has already been deployed. You are
going to see the same message if you undeploy this app and deploy it again.
The application itself is not configured optimally. This is just a warning
message telling you JSF listeners are already defined, and you might be
defining them again in web.xml.

(quick google search returns back stackoverflow page:

> As you can tell , I am novice to Tomcat. Please let me know if I missed on
> something.
> Appreciate all your help.

No worries. We have all been there. The key is to keep playing and
learning, and pay it forward ;)

Have fun!

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message