OutOfMemory in Tomcat

[Segah]

I have a serious problem with OutOfMemory exception in my webapplication
running under Tomcat. Having fallen down it pulls Tomcat along with it. I
viewed the amount of total and free JVM memory. The limit for JVM is 64M.
Could someone suggest how to increase this limit. I tried to increase JVM
memory by setting Xms and Xmx parameters to greater then 64M value but there
is no result. The limit of memory is still 64M.

 

[David Rabinowitz]

Search if you don't have memory leaks (General Maps or Sets are the
obvious place to look for them). The best is to use a profiler and to
see what takes all the memory. There are several free ones for Eclipse,
and JProfiler (which I've used) has an evaluation period and is very
comfortable to use.

David

 

[William Brogden]

I have a serious problem with OutOfMemory exception in my webapplication
running under Tomcat. Having fallen down it pulls Tomcat along with it. I
viewed the amount of total and free JVM memory. The limit for JVM is 64M.
Could someone suggest how to increase this limit. I tried to increase JVM
memory by setting Xms and Xmx parameters to greater then 64M value but there
is no result. The limit of memory is still 64M.

Did you do this setting in the catalina.bat file - the line that starts
set JAVA_OPTS
??

 

[bOOyah]

I have a serious problem with OutOfMemory exception in my webapplication
running under Tomcat. Having fallen down it pulls Tomcat along with it. I
viewed the amount of total and free JVM memory. The limit for JVM is 64M.
Could someone suggest how to increase this limit. I tried to increase JVM
memory by setting Xms and Xmx parameters to greater then 64M value but there
is no result. The limit of memory is still 64M.

This might help.

I've seen something similar to this before when debugging a Struts
app on JBoss. Are you continually deploying (maybe for test
purposes?) a web app containing raw JSPs? If so, the problem may be
related to Tomcat's JSP compiler. It used to leak memory every time
it compiled a JSP to a servlet. Eventually the server borks.
Increasing the amount of memory for the app only delays the
inevitable.

<off-topic drift>
Assuming the JSP compiler still leaks (I don't know for sure, I
haven't looked at this in over a year), you could try compiling the
JSPs *before* deploying them to the servlet container. It would
speed up the initial responsiveness of your web app too. What's
more, if you are using Sun's compiler you might be in violation of
its redistribution licence. I don't think you can ship Sun's JDK
(and therefore its compiler) with your app; another reason to do the
compilation up-front and just ship the compiled servlets. Does
anybody know different?
</off-topic drift>

 

[Sudsy]

This might help.

I've seen something similar to this before when debugging a Struts
app on JBoss. Are you continually deploying (maybe for test
purposes?) a web app containing raw JSPs? If so, the problem may be
related to Tomcat's JSP compiler. It used to leak memory every time
it compiled a JSP to a servlet. Eventually the server borks.
Increasing the amount of memory for the app only delays the
inevitable.

I've noticed exactly the same thing using Eclipse with JBoss and
JBoss-IDE. After a few deployment cycles you'll start to see the
synchronization errors. A little bit later you'll find that your
XDoclet builds fail to complete. At this point memory memory is
running low and I know it's time to bail. Sometimes I can still
exit Eclipse cleanly but often there will be errors thrown up as
it tries to terminate.
I often have to run 'fuser -n tcp 8099' to determine whether the
previous invocation of JBoss actually terminated. If not then I
have to manually kill the processes.
It's only fair to note that this can be a productive development
environment...when it works. ;-)

 

[Kle]

Hiya Guys,
this seems to be my problem exactly. I have just finished building a
medium sized web app using struts and deployed on jboss/tomcat.

Yesterday i got an email from the exception emailer that said out of
memery and the whole web server was gone. I was initially under the
impression that for some reason the java garbage collection wasn't
working correctly and that my app had caused it, but now it seems that
it may be the web server. The App had been running perfectly for about
3 weeks straight now and there hasn't been a single problem, i can
only assume that this will happen again.

Should i be looking towards the server or my app for the problem? Will
the profiler pick up only the leaks in my app or will it show me that
tomcat/jboss may be the problem?

I am relatively new to profiling and managing memory, i was always
under the impression that java would do it for me, so i just let
objects die at the end of the method.

Any help on this topic would be greatly appreciated.

Thanks for your time
Kle Miller

 

[Sudsy]

Kle wrote:

Should i be looking towards the server or my app for the problem? Will
the profiler pick up only the leaks in my app or will it show me that
tomcat/jboss may be the problem?

<snip>

Sorry, but I have neither the time nor inclination to ferret out
memory leaks. While a potent RAD (Rapid Application Development)
combination, I would have to recommend commercial products over
Eclipse/Tomcat/JBoss for a mission-critical app which has to be
available 24x7x365. No offence to the good people who contribute
to these open platforms intended.
If your app crashes after three weeks then how about bouncing it
every fortnight? Have you considered using JBoss solely for the
EJB and naming components and a separate Tomcat servlet engine,
perhaps along with an Apache front-end? Trying to debug the all-
in-one approach could be time-consuming and, ultimately, futile.
The individual components seem to have an enviable track record
of availability according to available documentation.
Good luck!

 

[Michael Scovetta]

If you're using a recent JVM (which you probably are), use the -Xms
and -Xmx switches to specify starting and maximum JVM memory sizes.
The switches are:
c:\>java -X
-Xmixed mixed mode execution (default)
-Xint interpreted mode execution only
-Xbootclasspath:<directories and zip/jar files separated by ;>
set search path for bootstrap classes and
resources
-Xbootclasspath/a:<directories and zip/jar files separated by ;>
append to end of bootstrap class path
-Xbootclasspath/p:<directories and zip/jar files separated by ;>
prepend in front of bootstrap class path
-Xnoclassgc disable class garbage collection
-Xincgc enable incremental garbage collection
-Xloggc:<file> log GC status to a file with time stamps
-Xbatch disable background compilation
-Xms<size> set initial Java heap size
-Xmx<size> set maximum Java heap size
-Xss<size> set java thread stack size
-Xprof output cpu profiling data
-Xrunhprof[:help]|[:<option>=<value>, ...]
perform JVMPI heap, cpu, or monitor profiling
-Xdebug enable remote debugging
-Xfuture enable strictest checks, anticipating future
default
-Xrs reduce use of OS signals by Java/VM (see
documentation)
-Xcheck:jni perform additional checks for JNI functions

However, I would FIRST try to figure out why it's crashing. Are you
redeploying applications that are storing static data? I've been
having problems with old deployments not being GCed after a
hot-deploy, and I'm still working through it, so I don't have any good
advice there.

Michael Scovetta