tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Tomcat 6.0.35 Crashed again
Date Thu, 11 Apr 2013 21:46:05 GMT
Hash: SHA256


On 4/11/13 9:52 AM, Daniel Mikusa wrote:
> On 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.
> A bigger heap will generally take longer to clean, but 4GB is not 
> particularly large.

Yes and no: GC time is dictated by the number of live objects (and how
much space they take up), not by the size of the heap space or the
amount of garbage. Moving a chunk of data from one heap space to
another is fairly quick, but if there are millions of tiny moves (8
bytes here, 8 bytes there), that's what takes the time. If you have a
10MiB byte array, it's going to move faster than 1M 8-byte pointers
randomly-scattered throughout the heap space.

> If you're concerned about the performance of the garbage collector,
>  I would suggest that you enable garbage collection logging. This
> adds very little overhead, simply logging an entry for every
> garbage collection that occurs. Each entry will indicate memory
> before and after the GC, plus how much time was spent performing
> the collection. You can use that to analyze the performance for
> your application.

Again, yes and no: when focusing on performance of the garbage
collector, enabling GC logging is pretty much the first step you want
to take. On the other hand, performance doesn't seem to be an issue,
here: (lack of) stability is the current issue.

>> 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.
> The JVM will start at -Xms and, if needed, expand up to -Xmx.
>> 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?
> It depends.  This can be good because it will prevent a few full
> GC's as the JVM expands from -Xms to -Xmx.  However, it can also
> waste memory if you allocate too much.


Re-sizing the heap does take time. If you expect to fully-utilize a
4GiB heap, you may as well allocate it all at once to avoid
heap-thrashing just to get up to 4GiB.

- -Xms4096M -Xmx4096M

On the other hand, the OP's problem is likely to be an actual *leak*,
in which case a huge heap only prolongs the inevitable. If I were
debugging this on a test rig, the first thing I would do is *reduce*
the size of the heap to make heap analysis easier.

>> 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?
> Spotting memory leaks is tricky and I'm not sure that what you're 
> proposing will be much help.  You could certainly look at the live 
> graphs and watch for a trend in memory usage increasing, but if
> the leak is small it would be very hard to spot.
> I would suggest that you add -XX:+HeapDumpOnOutOfMemoryError to
> your JVM options. This will create a heap dump when you encounter
> an OOME. You can then view that heap dump in jvisualvm or a
> profiler to see what was consuming the memory.


Heap dumps are no fun to analyze, but you might notice that you have a
whole bunch of objects you didn't expect to be sitting-around in the
heap (like java.sql.Connection, or huge byte arrays, or whatever).

I use YourKit (full disclosure: I get a free license as an ASF
committer) and it's got nice utilities for scanning heap snapshots for
some obvious potential problems (heap hogs, duplicate objects, arrays
with nothing but nulls in them, etc.). Most heap analyzers have tools
to let you find out how many objects of a particular type you have,
etc. and that may give you a quick idea of what may be going on. If
this is the first time you've ever looked at a heap dump, don't be
scared when you see the number of byte[], char[], and String objects
are still reachable ;)

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message