When you call Oracle Support with a problem like apj12 errors in your mod_jserv.log, middle-tier Java Virtual Machines (JVMs) crashing, or poor middle-tier performance, then it will often be suggested to increase the number of JVM processes. So, the key question that likely occurs to you is, "How many JVMs are required for my system?"
Processing Java Traffic in Groups
First, some quick background: web requests received by Oracle HTTP Server (Apache) to process Java code is sent to one of four different types of JVM groups to be processed. You can see this in the jserv.conf file:
ApJServGroup OACoreGroup 2 1 /usr/.../jserv.properties
ApJServGroup DiscoGroup 1 1 /usr/.../viewer4i.properties
ApJServGroup FormsGroup 1 1 /usr/.../forms.properties
ApJServGroup XmlSvcsGrp 1 1 /usr/.../xmlsvcs.properties
The number of JVMs for each group is signified by the first number on each line.
OACoreGroup is the default group. This is where most Java requests will be serviced
DiscoGroup is only used for Discoverer 4i requests
FormsGroup is only used for Forms Servlet requests
XmlSvcsGrp is for XML Gateway, Web Services, and SOAP requests
In the example above, I have two JVMs configured for OACoreGroup and one JVM configured for each of the other groups.
Factors Affecting Number of JVMs Required
Determining how many JVMs to configure is a complex approximation, as many factors need to be taken into account. These include:
Hardware specification and current utilization levels
Operating system patches and kernel settings
JDK version and tuning
Applications code versions, especially JDBC and oJSP
JServ configuration file tuning (jserv.properties and zone.properties)
Applications modules being used
How many active users
Rough Guidelines for JVMs
Luckily, Oracle Development have undertaken various performance tests to establish some rules of thumb that can be used to configure the initial number of JVMs for your system.
1 JVM per 100 active users
Use the capacity planning guide from Note 236124.1 "Oracle 9iAS 188.8.131.52 Discoverer 4i: A Capacity Planning Guide"
1 JVM per 50 active forms users
1 JVM is generally sufficient
In addition to this, Oracle generally recommends no more than 2 JVMs per CPU. You also need to confirm there are enough operating system resources (e.g. physical memory) to cope with any additional JVMs.
Your Mileage Will Vary
The general guidelines above are just that -- they're very broad estimates, and your mileage will vary. As I write this, the Applications Technology Group is working on a JVM Sizing whitepaper that will provide guidelines based on whether your E-Business Suite deployment is small, medium, or large. I'll profile this whitepaper here as soon as it's released publicly.
Until then, it's critical that you test your environment under load, using transactional tests that closely mirror what your users will be doing. It's useful to use automated testing tools for this, as you create your benchmarks.
Here are a couple of quick-and-dirty tools that might be useful in sizing your JVMs.
Script to determine "active users" for OACoreGroup
REM SQL to count number of Apps 11i users
REM Run as APPS user
select 'Number of user sessions : '
count( distinct session_id) How_many_user_sessions
from icx_sessions icx
where disabled_flag != 'Y'
and PSEUDO_FLAG = 'N'
and (last_connect + decode(FND_PROFILE.VALUE('ICX_SESSION_TIMEOUT'), NULL,limit_time, 0,limit_time,FND_PROFILE.VALUE('ICX_SESSION_TIMEOUT')/60)/24) > sysdate
and counter < limit_connects;
REM END OF SQL
How to determine "active forms users" for FormsGroup
Check the number of f60webmx processes on the Middle Tier server. For example:
The number of required JVMs is extremely site-specific and can be complex to predict
Use the rules of thumb as a starting point, but benchmark your environment carefully to see if they're adequate
Proactively monitor your environment to determine the efficiency of the existing settings and reevaluate if required
More on Java Memory Tuning Later
Once you've established the right number of JVMs to use, it's then time to optimize them. I'm intending to discuss Java memory tuning and OutOfMemory issues in a future article. Stay tuned