tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: java.lang.OutOfMemoryError: Java heap space
Date Wed, 07 Oct 2009 18:16:38 GMT
Hash: SHA1


On 10/6/2009 3:44 PM, Joe Hansen wrote:
> I did not check the CPU usage when the issue happened.  I just checked
> the web application logs and found that first there was an
> OutOfMemoryError, followed by MySQL errors when
> TWFotoSetListDAO.getAllFotosets tried to get a database connection.

It's possible that, if you really are grabbing photos (like, actual
images) from a database and fitting them into memory, you might just be
busting your heap yourself (rather than CAS, etc.). Are there large
objects that you store in memory and/or sessions?

> I am *guessing* :
> I changed the session timeout to 4 hours for the Jasig CAS
> Single-Signon web application. This stores a ton of tickets in memory.
> During a 4 hour period when there are more http requests, the 512MB of
> Java Heap space is not sufficient to store all these tickets. During
> that time OutOfMemoryError happens and all hell breaks loose
> subsequently.

Wow, those "tickets" seem very heavyweight. Try this when the server is
"quiet" and then, later, when it's getting stormed:

$ jmap -histo [jvm pid] > heap.log

Then, go into the heap log and see what's taking up so much of your
memory. For instance, if I run this against my own JVM running in
development, here are the top 10 objects in memory:

Size    Count   Class description
- -------------------------------------------------------
10785200        98394   char[]
5548488 40283   * ConstMethodKlass
2911352 7238    byte[]
2465208 102717  java.lang.String
2259496 40283   * MethodKlass
2212736 54518   * SymbolKlass
2171032 3767    * ConstantPoolKlass
1912032 7936    int[]
1761184 38585   java.lang.Object[]
1500112 3767    * InstanceKlassKlass

These are the objects taking up most memory. If you look at the "count"
column, you can see how many of the objects are in memory. I suggest
looking at both the "size" and the "count" columns, because your
understanding of the "size" of an object and the JVM's notion may
differ: most heap space is taken up by byte and char arrays and things
like that, but then encapsulated into "larger" objects that, themselves,
take up very little space.

You may find that you have thousands of CAS tickets in memory and that
they are very heavy. You may also find that the tickets themselves
aren't the problem, but that a 4-hour session timeout leads to sessions
with huge amounts of cached information in them. It's possible that your
webapp is simply being careless with memory if you want a 4-hour session

You might want to invest in a real memory profiler to see what is
happening. These products can give you a better picture of "large"
objects that you can look at to make decisions as to where you will
apply your efforts.

- -chris
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -


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

View raw message