On 16/11/2009 23:54, Elli Albek 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:
1a. Old code? Look for improperly closed DB connections.
1. Sessions
2. Application code
3. Other webapps
p
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
