Latest JVM Tuning Recommendations for Apps 11i

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


Comments:

Mike, Nice Article,
Can you direct me to metalink note
which has more info on this setting "-DCACHEMODE=LOCAL" in the jserv.properties

Posted by sam on May 18, 2007 at 06:38 AM PDT #

Sam,I've gotten confirmation that this parameter's setting should never be changed from its default TRUE setting.  This parameter affects the functioning of the Java caching infrstructure, and Concurrent Manager hardcodes its value to TRUE.  Any manual changes may result in setup inconsistencies, for example, when JServ's setting is FALSE and Concurrent Manager's setting is TRUE.  Such inconsistencies will result in unpredictable issues with your environment.Regards,Steven

Posted by Steven Chan on May 22, 2007 at 03:42 AM PDT #

Hi,

Kindly give me file name where i can change jvm parameter. JVM with heap size where i can define this parameters.

Regards,

Hammad

Posted by Hammad on March 11, 2009 at 04:46 PM PDT #

Hello Hammad,

You should make all configuration changes using AutoConfig as it is not supported to make manual changes to the configuration files directly

For information on AutoConfig see Note 165195.1 if using Rel 11i and Note 387859.1 for Rel 12

The files that AutoConfig will update are jserv.properties with Rel 11i and $ORA_CONFIG_HOME/10.1.3/opmn/conf/opmn.xml in Rel 12

Hope this helps

regards

Mike

Posted by Mike Shaw on March 11, 2009 at 05:06 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
4
5
6
7
8
9
10
11
12
13
14
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today