What I have found works well in some circumstances where you do not have a profiler to hand. 1. Look for static declarations in your code that point to singletons or collection objects. They might just grow and grow.... 2. You may not be using third party libs correctly, e.g. Not closing connections, performing cleanup etc. RTFM just in case. 3. Perform amputations on your code if possible i.e. replace methods with dummy invocations. You will *eventually* find the source of festering objects that are not being gc'd. Tony
On Mon, 16 Nov 2009 15:54 -0800, "Elli Albek" <e...@sustainlane.com> wrote: > You can try getting an object dump from a profiler and see which > objects are the source of memory starvation. Simple JSPs are very > unlikely to cause memory starvation, but you mentioned “application > code”, which implies that you have more than simple JSPs. > > A few things you want to cross off your performance check list, which > will not solve your problem, but are generally necessary: > 1. JVM -server option, just in case > 2. Disable session persistence > 3. If you application does not use sessions, disable them for all JSPs > (typical place to do it is header JSP include) > 4. Force session termination, no long running sessions. > 5. Remove all apps that you do not need. Tomcat comes with a few built > in apps and those are not trivial to find. Make sure conf/Catalina and > all its sub directories contain only apps that you need. Host manager > and such should be deleted. Same with war files. > > What you describe in your memory graph is a simple memory leak. > Generally, I would look in that order: > 1. Sessions > 2. Application code > 3. Other webapps > > 1 and 3 are easy to deal with. If you don’t need sessions make sure > they are not created at all. If you do, force session termination > after a few minutes in master web.xml or other XML files. Notice that > one file can define a value and another can overwrite it, so you have > to make sure all are checked. > > If that does not work, application code is the next candidate. You can > start with an object dump with a profiler or a simple code review/step > through in a debugger. > > E > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
