In my previous article “Configuring Middle-Tier JVMs for Applications 11i” I provided some suggestions in the paragraph “Rough Guidelines for JVMs” as to how many JVMs could be implemented as an initial starting point.  Subsequent to that blog article,  Guidelines to setup the JVM in Apps 11i“

(Metalink Note 362851.1) has been released which includes the ATG Performance Group’s official recommendations, some of which are different than stated in my original article. 

JConsole_heap:


In this article I would like to go into a little bit more depth about the newly published recommendations.  I will focus only on the OACoreGroup JVM and not consider the Forms Servlet, Discoverer or XML Service JVM settings.  I will also assume the reader has some familiarity with Java and eBiz 11i already and is also using eBusiness version 11.5.10 with JDK 1.4 or 1.5.   


Background

From a CPU utilization perspective, there is no need to run more than 1 JVM per CPU because of the following reasons:

  • The JVM uses native threads and the native threads can be scheduled on any of the available cores/CPUs. 
  • Multiple parallel Garbage Collection (GC)  threads — introduced in 1.4 — are spawned.  Running multiple JVMs per CPU could result in an excessive number of background and GC threads. 
  • Multiple JVM increases the number of JDBC connections required and there is a memory and CPU overhead for each JVM process. 

For the majority of our web applications, more than 90% of the memory allocations are transient (for the life of the request or page), so new space GCs dominate much more than old generation GCs.  Old generation GCs are usually only a problem with older versions of Applications code or modules such as Configurator which load a large amount of objects (e.g. config model) in the old space.


Why increase the number of JVMs

There are several reasons why you would want to increase the number of JVMs:

  1. Minimize GC pause overhead
  2. Reduce the JVM heap size
  3. Minimize contention due to hot synchronized methods (i.e. monitor contention).
Based on Oracle’s performance testing, benchmarking, and our experience with working directly with enterprise-class customers, we have determined that 100 users per OACore JVM has generally proven to be a practical and performant number.   Increasing the session.timeout parameter in zone.properties above the 30 minute default may increase JVM memory requirements.

Recomendations in summary

Guideline #1:   For the OACoreGroup JVMs start with the lower of the following two values:

  1. Number of cores on the middle tier
  2. Peak Concurrent users / 100
For example: 

If you have 2 x Dual Core CPUs in your server and have 500 peak users, then 4 JVMs is the recommended starting point, since the number of cores is the lower number.  However, if you only had 300 peak users, then you would configure 3 JVMs as a starting point as this is now the lower figure.


Guideline #2:  Size your maximum heap size as either 512 MB or 1 GB.  If you start with 512 MB and find that more memory is required, increase to a maximum of 1 GB.   If more memory than 1 GB is required, then add another JVM instead (free physical memory allowing) to increase the total memory available overall. 

For example:

You are using 1 x JVM with 1 GB heap size and find you need to increase memory.  Configure your system for 2 JVMs, each with 750 MB heap size, thus providing 1.5 GB in total.


Your mileage will vary


As always, these recommendations are generalised and can only act as a suggested starting point for your system.  As mentioned in my previous blog article, there are many factors that effect how the JVM is utilized, so you will need to undertake representative testing to prove that the number of JVMs you select is suitable for your specific user load and profile.

Related