tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juha Laiho <>
Subject Re: Tomcate 5.5.23 JAVAOPTS
Date Wed, 04 Jun 2008 18:31:53 GMT
karthikn wrote:
> Will this config work ?
> O/s = UNIX 11 PA Risc
> SDK : J2SDK16
> TOMCAT 5.5.23
> RAM = 2 GB
> The Web application is simple and uses JNI to connect to UNIX LOCAL 
> Application
> JAVA_OPTS="-server -Xms200m -Xmx2548m -XX:+UseParallelGC -verbose:gc"

As was mentioned in another response, you should find a way to test
this somehow (perhaps with a series of smaller loads, and graphing
the results in terms of memory and thread usage, and extrapolating
from the results you get).

However, I'd be very wary of letting Java to overcommit your physical
memory (i.e. letting Java use more memory than the physical memory
you have on the system). If I understand (and guess) correctly,
you're planning to dedicate this machine to the single JVM running
Tomcat. If so, I'd limit the JVM heap to something like 1.5GB rather
than the 2.5GB you're proposing above. The rationale for that is that
there are other things running on the machine than the JVM, and they
need memory, too (the OS at least, and the essential processes). Also,
the -Xmx only limits the heap usage, but a JVM allocates other memory
regions in addition to the JVM heap - and thus can use more than is
allocated for the heap, esp. if the heap is fully allocated.

If you went ahead with the plan you proposed, you might well end up
in a situation where your JVM hits a memory shortage situation, leading
to a cleanup that would start paging your _ACTIVE_ JVM heap pages out
to disk in order to release objects from such heap pages that had been
pushed out to swap due to inactivity. As disk accesses are significantly
slower than real memory accesses, your application performance could
suffer - and in this kind of situation, the adverse effects might hit
exactly at the time of sharply increasing usage, leading to very rapidly
deteriorating performance. The use of parallel GC, while a good idea in
itself, might be an additional factor in making the slowdown even more
dramatic in a memory shortage situation (if a parallel GC cannot free
memory rapidly enough, the JVM will stall and perform a non-parallel
GC -- and having to fish memory pages out of disk might well be a big
enough slowdown to cause the parallel GC to be slow in releasing memory).

So, in general, keep JVM out of your paging area. If you're planning to
dedicate a machine mostly to a single JVM, limit the JVM memory usage in
such a way that there will be little or no competition of physical memory.

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message