tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <christopher.d.schu...@comcast.net>
Subject Re: OutOfMemoryError
Date Tue, 02 Dec 2003 21:23:48 GMT
Trenton,

>>>Are you using the context reloading feature?  "reloadable=true" or
>>>using
>>>the tomcat manager app will cause this to happen eventually.
>>
>>Really?  Prove that please...
> 
> 
> Actually, I can't prove it in his instance, but I have proved it time and time
> again on ours.  I'm using 4.0.4 right now though so I haven't verified 4.1.x.
> But, I heard that this is still the case in 4.1.x.
> 
> To reproduce this problem just reload a context over and over.  Depending on
> how much memory it uses, it will start throwing OutOfMemory exceptions long
> before the -mx JVM parameter value is ever reached.  eg.  I do a ps on linux
> and it shows it as using like 140M or something like that and it already
> starts throwing out of memory exceptions.

Aah. I think I see a part of the problem. First of all, the amount of 
memory shown by 'ps' is completely irrelevant, except that it shows how 
much memory that the OS has allocated to the Java process. This is 
allowed to be more than the "max heap size" set for Java.

The heap is not related to the amount of memory the OS allocates, except 
that the OS report will always be larger than the heap report from Java.

You can get an OOM even if you have the heap set to 1GB and yet the 
process only has 50MB used. This is because OOMs usually happen *while 
the GC is doing its work*. I'm not sure if there's another thread that 
increases the actual size of the heap for you, but if so, I'm sure it's 
related to the GC anyway.

So, moving on, what usually happens is that a "low memory" condition 
triggers a GC (usually a "full" GC). When the GC runs, it needs some 
memory to work with. If it cannot allocate memory for itself, it will 
die with an OOM. If the heap hasn't increased, yet, then the GC cannot 
allocate more objects on the heap to do it's thing. That can explain why 
you get an OOM when you are way under the heap "size" in the output of ps.

> With our applications that we're running, we can usually get away with roughly
> 5-10 context reloads.

Do you have any 3rd party containers or such that live outside of the 
context (their JARs would be in CATALINA_HOME/server/lib or 
CATALINA_HOME/common/lib -- someone please confirm that the second of 
these two does *not* get discarded along with the rest of the context 
upon reload). If you are using 3rd party containers like this, they will 
not dump their contents when you re-load the servlet context. If you 
have static "singleton" instances of these, then you'll likely fill up 
memory all the time.

This could also be related to the "Java doesn't GC java.lang.Class 
objects" thread that's going around this week, too.

-chris


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message