If your JVM runs out of heap space, you should get an
OutOfMemoryException thrown. Same, if you don't have sufficient stack
space, you should get a StackOverFlowException.
I had a problem with a JSP that sometimes would take as much as 15
minutes to serve. It creates a table of sometimes a few hundred rows,
each containing a selection box and a submit button. I ended up
rewriting it as a Java class that first builds the outtput message in a
StringBuffer using append() and then writes the buffer to the output
stream in a single operation. That increased performance by more than
one order of magnitude. I suspect that there is an issue with the way
Jasper created servlets use the out.write()/out.print() methods.
Lars
-Original Message-
From: John Turner [mailto:[EMAIL PROTECTED]
Sent: Friday, July 11, 2003 1:38 PM
To: Tomcat Users List
Subject: Re: Need help with performance issue - Tomcat 4.1.X
Like I said, I'm no guru. Sounds like you need to bust out a profiler.
John
On Fri, 11 Jul 2003 20:34:40 +, [EMAIL PROTECTED] wrote:
But again, the mx is only setting the heap size, not the whole JVM.
The
thread stack is controlled with an entirely different parameter for
example.
I found this with a quick search:
The -Xmx setting controls the maximum size of the Java heap.
However, the Java heap represents only part of the memory taken up by
a
running Java application. There is space required for code, data space
used
by the JIT, plus any memory malloced by native code drivers associated
with
the application running in the JVM. So the overall memory picture for
Java
applications turns out to be more complex than just the -Xmx value.
-- Dave
I have no idea, but based on past experience, if you are using more
RAM
than you've allocated, then you have a swap situation. If the max
setting wasn't an actual max, and you could blow past it whenever you
needed it, why on earth would you need it in the first place?
John
On Fri, 11 Jul 2003 20:24:48 +, [EMAIL PROTECTED]
wrote:
I definitely don't know enough about how the memory settings in
java
to be of much use on this part. I do not know if we've tried 512.
We
probably should.
As for the 327, is that actually unreasonable? The mx setting
specfies the maximum heap size. Can the thread stack (specified
using
-Xss, which we're not using) be taking up the remaining 75MB? We
have
about 40 threads started right now.
Like I said, I don't know enough about java's memory allocation,
but I
didn't think that the -Xmx set the maximum allowable total memory
for
the JVM. Am I mistaken?
Even if memory were a problem, which it may be, would that account
for
a 20 second delay between serving a page and closing the
connection?
Remember that we currently have no load and only a couple users on
the
system.
-- Dave
I'm certainly no guru, but if you are setting a max of 256 and
then
your app is soaking up 327 with no load whatsoever, I'd say you
have
a problem. Have you tried a max of 512?
John
On Fri, 11 Jul 2003 20:08:10 +, [EMAIL PROTECTED]
wrote:
We are currently starting up with -Xmx256M. Java is currently
using about 327MB and has been that way for hours. I haven't
really seen any fluxuations at all, which leans me away from the
garbage collection issue.
I created a hello.jsp, which is completely separate from our
application. Same results. It takes about 30 seconds to return.
In the hello.jsp, the results of the page return instantly to
the
browser, but then it's as if tomcat just won't close the
connection
to the browser. The page is there, fully rendered, but just
sits
there waiting for the server to tell it it is done. Is there
some
way that the tomcat connections could be failing to terminate
properly?
Our current maxProcessors = 75
acceptCount = 10 (which is probably low but right now we have
only
a couple users on the system).
We're not using 1.4 so those options are out.
-- Dave
Could be a Memory Leak/Garbage Collection issue (we had a
similar
problem with a memory intensive app),
maybe your heap is too small and java is running many Full
GC's.
Start java with -verbose:gc and look in
tomcat/logs/catalina.out
for Garbage Collections.
(set Environment Variables JAVA_OPTS or CATALINA_OPTS in
bin/catalina.sh to do this in Tomcat)
Try using a bigger Heapsize (though if you've got a Memory Leak
that will only delay your problem)
or set initial Heapsize to same as maximum, for example 128MB:
-Xmx128m -Xms128m
Modify the Connector you are using to access Tomcat (in
tomcat/conf/server.xml) and
try using more Tomcat Processors (maxProcessors=XX) or a bigger
accept queue length (acceptCount=XX)
(test value for acceptCount: at least
