JVM Tuning for SOA Suite Applications

JVM Tuning for SOA Suite Applications :
1. General Considerations

JVM parameters play a major role in the BPEL engine's performance. The major factors that affect
performance relate to the heap size.

JVM Heap Size:
--------------------
The amount of heap required varies based on the application and on the available memory, for most
j2ee server applications containers, if you have sufficient memory, then it would be recommended
to use a heap size of 512 MB or larger.

To maximize performance, set the maximum heap size to accommodate application requirements and
make sure that the total memory consumed by all of the JVMs running on the system does not exceed
the memory capacity of your system.

Maximum heap size:
---------------------------
The maximum heap size controls how much memory the JVM can use. If your BPEL instance runs on a
dedicated machine, set this as high as the maximum addressable memory space of your Operating
System.

Determine the maximum heap size for yourplatform using one of the following methods:

1.On Windows you should set the max heap to 1300m and the min heap to 500m

2.Consult your platform vendor documentation/Web page for information regarding the maximum heap
size for your particular JVM version.

3.Determine the maximum heap using a binary search for your platform/JDK combination by running
Java from the command line and specifying the maximum heap. For example,

java -mx3000m -version

You may see a message similar to the following:

Error occurred during initialization of VM
Could not reserve enough space for object heap

In this case, decrease the maximum heap value until you do not get the error message (and the
version is displayed). You may wish to start by setting the maximum heap to 1000M.

For example:

a) Start at 1000M
b) If that works, set it to 3000M.
c) If 3000M doesn't work, set it to 2000M
d) Continue until you find your platform/JDK maximum heap size.

Once you have determined the maximum heap size, specify it in your Jserv.properties file such that
the Java maximum heap is either the platform maximum or 3GB, whichever is smaller.

For example, your Jserv.properties entry might be:

wrapper.bin.parameters=-Xms500M -Xmx -XX:NewSize=128M -XX:MaxNewSize=128M

In this example, substitute the actual value for .

For example:

wrapper.bin.parameters=-Xms500M -Xmx3000M -XX:NewSize=128M -XX:MaxNewSize=128M

Initial heap size:
--------------------
Sun Micro System recommends setting the initial (minimum) heap size to be equal to the maximum
heap size for optimal performance. The following option starts JVM with an initial heap size of 2GB:
-Xmx2048m -Xms2048m

Eden Space:
--------------------
Another important heap configuration are the garbage collector's generational settings. The
garbage collector optimizes collection by classifying objects by how long they live. Most of the
BPEL engine's objects are short lived, thus they live in the eden space. We recommend sizing the
eden space to be 60-70% of the total maximum heap size. The following command line starts Java
with a eden sizing that is 60% of the maximum heap size:
-Xmx2048m -Xms2048m –Xmn1228m

Survivor Ratio
------------------
The young generation consists of eden plus two equally sized survivor spaces. Objects are
initially allocated in eden. One survivor space is empty at any time, and serves as a destination
of the next, copying collection of any live objects in eden and the other survivor space. Objects
are copied between survivor spaces in this way until they are old enough to be tenured, or copied
to the tenured generation.

To size the survivors and eden generation the following options can be used:

allocate 6/8 to eden space and 1/8 to each survivor space

(allocated from -XX:NewSize=1228m -XX:MaxNewSize=1228m -XX:SurvivorRatio=6

Eden : 6/8 * 1228 = 921

Survivors : 1/8 * 1228 = 153 ( survivor 1 and 2 are of equal size )

Tenure : total heap - new size = 2048 - 1228 = 820

-Xmx2048m -Xms2048m –Xmn1228m -XX:NewSize=1228 -XX:MaxNewSize=1228m

-XX:SurvivorRatio=6

Permgen
--------------
The permanent generation holds data needed by JVM to describe objects that do not have an
equivalence at the Java language level. Eg: objects describing classes and methods.

The Permanent Generation is allocated outside of the heap.
- The defaults are typically too small for J2EE Applications.
- Also note, using certain java.lang.reflect can generate temporary class definitions that can
easily impact the permanent generation
- Consider setting –XX:MaxPermSize equal to –XX:PermSize to minimize major collections
-XX:MaxPermSize=128m –XX:PermSize=128m

Aggressive heap setting
---------------------------------
If your machine has multiple CPUs, it is recommended to use -XX:+AggressiveHeap JVM flag. The
-XX:+AggressiveHeap option inspects the machine resources (size of memory and number of
processors) and attempts to set various parameters to be optimal for long-running, memory
allocation-intensive jobs. The following option starts JVM with aggressive heap settings:
-Xmx2048m -Xms2048m –Xmn1228m –XX:+AggressiveHeap

GC Parameters to Help Tuning with Sun JVMs
---------------------------------------------------------------
-verbose:gc
-XX:+PrintGCDetails
-XX:+PrintHeapAtGC
-XX:+PrintTenuringDistribution

These will give the details for the tenuring distribution so you can see if you allocations are
working the way you expect.

Note : There are many factors which influence the JVM settings, not only the size of the RAM, but
also the other applications running on the same machine etc. Because all the memory and other
resources on a machine is not available to container running the SOA Suite. The Operating System
also needs some resources plus other servers and applications.Also within the single server there
are multiple JVM running. Depending on the type of install, in case of advanced installation a
minimum of two instances will be running - home, oc4j_soa. Even if you have ample of resources
still having a very large heap for the container to work with is counter productive because of
java Garbage collection. The larger the heap the more time it takes to do GC hence the impact on
performance.

For example, for a machine with 4GB there is not much space anyway, you can simply use one OC4J
instance with one JVM per component.

What you should consider is not exceeding -Xmx1024m per JVM running OC4J, but rather consider
scaling out to multiple JVMs.