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 Tue, 16 Nov 2010 02:42:34 GMT
Hi Chris,

> -----Original Message-----
> From: Christopher Schultz []
> Sent: Monday, November 15, 2010 09:04 PM
> To: Tomcat Users List
> Subject: Re: Tomcat 6.0.29 using more and more RAM until it collapses?
> Hash: SHA1
> Brian,
> On 11/14/2010 1:30 AM, Brian wrote:
> > 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 above is certainly compounding the issues below...
> > - 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!
> Yes: hundreds of MBs of buffers for each webapp instance that is not cleanly
> undeployed can certainly bust your heap. I'm not entirely sure how Tomcat
> expects to free all those buffers (or simply relies on GC), but it's certainly
> possible that retaining some reference to a webapp-loaded object ends up
> keeping those buffers around forever, unable to free them.

mmm.... OK, this is what I have understood so far:
- The tag body buffers are stored in a growing array of chars. There is a pointer that know
which of the chars is the last one being used. Initially, they are 512 chars, but if a bigger
buffer is needed, the quantity of chars increases. But it never decreases. So if at one instant
1 million of chars are needed, the array will grow for that, but will never shrink even if
the next use of the buffer is for a 10 characters value (I'm assuming that there is a pool
of buffers to reuse, that the buffers are part of a pool).
- Some some reason (I don't know why), sometimes Tomcat thinks that needs a huge buffer, so
it makes the array to increase to millions of chars. I have no such big pages in my site,
so I can't understand how can that happen, but it does. Then, the buffer stays with millions
of chars, so the object uses millions of bytes. Do you think a leak has something to do with
- I think Tomcat doesn't even expect to free those buffers as you say, but use them again
and again instead, cause I THINK (correct me if I'm wrong) that they belong to a pool. So
they just say like that forever.
- Now that I set the flag, everytime Tomcat decides to empty the content of the buffer so
it will be used again (emtpy=set the lastUsedCharPointer to cero), it sets it to a new array
of 512 bytes if it was bigger that that.
I don't know if this issue is retaled to the other one (leaks at undeployment).

> That isn't a standard option because in (most?) cases where the buffers are
> being constantly used, the performance increase is significant.
> Since your webapp is both misbehaving and being re-loaded often, you must
> use this workaround.

Well, I don't know how can Tomcat think that a 8MB buffer is needed in my site for a page.
That is the source of the problem. But even if its my fault somehow (leaks in my code), or
just the planets aligned so this will happen, I think Tomcat should always think "If the buffer
got too big when I clear it, I will make it again to be 512 bytes". That just means creating
a new array of chars. How much cost would that be?

> I don't mean to say that you are doing anything wrong, but our production
> webapps aren't undeployed for months at a time -- between releases. What is
> it that requires you to redeploy your webapp so often?

I'm constantly developing, improving and correcting my site. 

> > - 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!
> Again, these caches might expect to die with the rest of the webapp. If they
> don't you'll certainly exhaust your heap after a couple of reloads.

Well, given that I have about 20 WARs, these caches were using about 200MB of ram. Even if
my app never leaks when redeploying and doesn't degenerate, or even if I would never stop
my app, I don't like to spend 200MB in these caches. I could also limit the size of the caches,
but I started trying to disable them, and my site still runs pretty fast without these caches

> I believe Chuck and Mark have both suggested that you simply fix your
> webapp's leaks (as reported at un-deploy) or post the warning messages to
> allow us to help you fix those. If you fix your resource leaks, you may be able
> to restore the default value for LIMIT_BUFFER and thereby restore
> performance of your JSPs.

Oh, I would love to do that, but I still don't know the reason of the leaks! The Tomcat manager
just tells me which apps left leaks, but not why or how did that happen.


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

View raw message