Hi Chris, > -----Original Message----- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > 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? > > -----BEGIN PGP SIGNED MESSAGE----- > 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 that? - 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 now. > 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: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
