-----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. 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. 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 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. 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. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzh5nsACgkQ9CaO5/Lv0PCqYwCgl6Op7gScXfTvzfupBQIQ/pPH rOUAoJwK7794A/SpbHEW3JQ8k5U1Fv36 =NajF -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
