I think that this is a garbage collection issue.
Enable the garbage collection output to see if that's the case (the
"-verbose:gc" flag) . I struggled with this myself just a month ago and
ended up learning more about Java GC than I ever wanted to know. The
gist of it is that when the JVM runs out of heap memory and does a major
collection, it will pause all threads while it's collecting. It doesn't
matter what the priority of the thread is or whether or not you are
using a parallel GC. As you approach heap memory limits, the GC is
working its tail off trying to recover memory wherever it can, pausing
all JVM activity as necessary. I have a feeling that you'll see more
and more GC calls as the app grinds to a halt.
A couple of points:
Disabling GC hints can sometimes dramatically increase performance if
you're not actually running out of memory. Don't assume that just
because *your* code isn't requesting a collection that a third-party
library isn't.
As someone pointed out elsewhere, you're going to want to switch to a 64
bit OS and JRE at some point, if you want to take full advantage of all
that RAM.
In case you're curious, these are the JRE flags that we ended up running
with:
-XX:+UseParallelGC
-XX:+AggressiveOpts
-XX:+DisableExplicitGC
-XX:+UseAdaptiveSizePolicy
-XX:MaxPermSize=512m
(Obviously the MaxPermSize flag is dependent on how your applications
allocate memory.)
A profiler will be helpful too. I've had some success using the one
built-in to Netbeans.
Good Luck!
Brantley
Matthew Laird wrote:
We're pulling our hair out with a Tomcat issue.
We have an in-house application running on Tomcat 5.5 with Sun JDK 1.6.
The machine is an x86 dual-CPU, quad core (8 cores total) with 16GB of
RAM. We're running OpenSuSE 10.2, 32-bit. Java memory size set to 2GB,
multi-threaded GC enabled.
What occurs is when a user clicks a certain kind of analysis on the
website, data is retrieved from a database and then a lot of formatting
is done before returning it to the user. This typically causes 100% CPU
usage for this thread for a few minutes (bioinformatics application,
that part isn't going to change).
Unfortunately what then occurs is all other threads suddenly become
unusably slow. The entire web application grinds to a halt until this
thread that's running hot completes.
Looking at top, it appears that these threads aren't spreading among all
the cores. I see one core go to 100% usage, and the others stay at 100%
idle. So we're running multi-thread, but because everything is staying
on the same core, we're still getting thread contention that's bringing
the entire application to its knees.
The only time I began to see the other cores actually start being used
is when I enabled multi-threaded GC. But that doesn't give much
improvement since the threads responding the web requests are still all
on the same core.
I'm not sure how to convince the Tomcat/Java container to spread its
threads among the cores.
Thanks.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
