tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian" <>
Subject RE: Tomcat 6.0.29 using more and more RAM until it collapses?
Date Sun, 14 Nov 2010 06:30:07 GMT
Hi Chuck,

Thanks for your explanations.
My PermGen seems to be normal, low and steady.

It seems that I solved my problems! So far, these are my conclutions:

- Very often, when I restart/redeploy my app, some garbage is left in the memory. I don't
know why, given that my code closes everything (relationships with the database, etc), unloads
the JDBC drivers, etc. Now I'm restarting Tomcat very often, instead of just restarting/deploying
my app. 
- The Tag bodies made some buffers to grow to huge objects. I have told Tomcat to decrease
those buffers if they get bigger than the standard size (512 bytes), and now the problem seems
to be gone! I wonder why isn't that "....LIMIT=true" directive a standard. I bet millions
of sites are having the same problem, and they don't even imagine what a memory profiler is,
and how this can be happening. This problem was swallowing hundreds of MB!
- I configured the Context so it wont use a cache for the static pages. At least for now,
I made this to all the contexts. Maybe I will restore this capability to just my java app
that doesn't have more than a few static resources, and keep it disabled for the 20 WARs full
of static pages. This problem was also swallowing hundreds of MB!


> -----Original Message-----
> From: Caldarale, Charles R []
> Sent: Saturday, November 13, 2010 11:03 AM
> To: Tomcat Users List
> Subject: RE: Tomcat 6.0.29 using more and more RAM until it collapses?
> > From: Brian []
> > Subject: RE: Tomcat 6.0.29 using more and more RAM until it collapses?
> > the Eden Space is barely used (10MB right now). The survivor space is
> > even less used (1MB right now).
> An object is normally created in Eden and will migrate to survivor if still
> reachable during the next minor GC.  In most applications, the vast majority of
> objects become unreachable very quickly, and never make it to a survivor
> space.
> > But the Tenured Gen space has 120MB right now! In fact, when my JVM
> > start to eat houndreds of MB, most of that goes to the Tenured Gen.
> Once the survivor space fills up, long-lived objects migrate to tenured, where
> they stay until the application discards them.  Very large objects may be
> initially allocated in tenured if they won't fit in Eden.  Anything you see in
> tenured has either been around for quite some time or exceeds the Eden
> allocation threshold.  The dead objects in tenured space won't be cleaned out
> until a major GC occurs; the JVM tries to minimize the number of those since
> they take quite a bit more time than a minor GC.  You can force a major GC
> with the JConsole button.
> > The perm gen is using 22MB right now, which is not a lot so I guess it
> > is normal.
> A one-time look at the size of the PermGen isn't interesting; you need to see
> whether it increases over time, especially after restarting a webapp.  If it does
> increase after a restart, that means the old instance of the webapp is still
> hanging around.
>  - Chuck
> PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If
> you received this in error, please contact the sender and delete the e-mail and
> its attachments from all computers.

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

View raw message