JVM Tuning
Resin 3.0

Features
Installation
Configuration
Web Applications
IOC/AOP
Resources
JSP
Servlets and Filters
Portlets
Databases
Admin (JMX)
CMP
EJB
EJB 3.0
Security
XML and XSLT
XTP
JMS
Performance
Protocols
Third-party
Troubleshooting/FAQ

Server Caching
JVM Tuning
FAQ
Scrapbook
Server Caching
Performance
FAQ

Better performance in production servers is possible with proper configuration of JVM parameters, particularily those related to memory usage and garbage collection.

  1. Heap size
    1. Heap size does not determine the amount of memory your process uses
  2. Garbage collection
  3. Stack size
  4. Monitoring the JVM

Heap size

The allocation of memory for the JVM is specified using -X options when starting Resin (the exact options may depend upon the JVM that you are using, the examples here are for the Sun JVM).

JVM option passed to ResinMeaning
-Xmsinitial java heap size
-Xmxmaximum java heap size
-Xmnthe size of the heap for the young generation

Resin startup with heap memory options
unix> bin/httpd.sh -Xmn100M -Xms500M -Xmx500M
win> bin/httpd.exe -Xmn100M -Xms500M -Xmx500M
install win service> bin/httpd.exe -Xmn100M -Xms500M -Xmx500M -install

It is good practice with server-side Java applications like Resin to set the minimum -Xms and maximum -Xmx heap sizes to the same value.

For efficient garbage collection, the -Xmn value should be lower than the -Xmx value.

Heap size does not determine the amount of memory your process uses

If you monitor your java process with an OS tool like top or taskmanager, you may see the amount of memory you use exceed the amount you have specified for -Xmx. -Xmx limits the java heap size, java will allocate memory for other things, including a stack for each thread. It is not unusual for the total memory consumption of the VM to exceed the value of -Xmx.

Garbage collection

(thanks to Rob Lockstone for his comments)

There are essentially two GC threads running. One is a very lightweight thread which does "little" collections primarily on the Eden (a.k.a. Young) generation of the heap. The other is the Full GC thread which traverses the entire heap when there is not enough memory left to allocate space for objects which get promoted from the Eden to the older generation(s).

If there is a memory leak or inadequate heap allocated, eventually the older generation will start to run out of room causing the Full GC thread to run (nearly) continuously. Since this process "stops the world", Resin won't be able to respond to requests and they'll start to back up.

The amount allocated for the Eden generation is the value specified with -Xmn. The amount allocated for the older generation is the value of -Xmx minus the -Xmn. Generally, you don't want the Eden to be too big or it will take too long for the GC to look through it for space that can be reclaimed.

See also:

Stack size

Each thread in the VM get's a stack. The stack size will limit the number of threads that you can have, too big of a stack size and you will run out of memory as each thread is allocated more memory than it needs.

JVM option passed to ResinMeaning
-Xssthe stack size for each thread

-Xss determines the size of the stack. You may even be able to make this value as low as 1k: -Xss1k. If the stack space is too small, eventually you will see an exception class java.lang.StackOverflowError .

Some people have reported that it is necessary to change stack size settings at the OS level for Linux. A call to ulimit may be necessary, and is usually done with a command in /etc/profile:

Limit thread stack size on Linux
ulimit -s 2048

Monitoring the JVM

Sun provides the jvmstat tools , which are useful for monitoring the JVM. They are particularily good for monitoring garbage collection, helping you gather the information you need to optimize your memory settings.


Server Caching
Performance
FAQ
Copyright © 1998-2005 Caucho Technology, Inc. All rights reserved.
Resin® is a registered trademark, and HardCoretm and Quercustm are trademarks of Caucho Technology, Inc.