appsdba4all: January 2015

The Java.lang.OutOfMemoryError: Java Heap Space Error which means that the JVM ran out of memory and so we need to increase the value of the -Xmx to a higher value.

The recommended number of JVM's and memory will depend on how many CPU's you have on your system.

Please follow the following :

Take a backup of the file $INST_TOP/apps/SID_HOSTNAME/ora/10.1.3/opmn/conf/opmn.xml

A) Increase nprocs(JVM's) =”half of the number of CPU's you have”

It depends on the number of cpu's you have.

If you have 6 cpus in server you can increase this JVM upto “3”.

B) Now we have to increase the memory for JVM.

Here nproc is number oc4j instance.

So to find out how much memory we need to increase multiply Xms with nproc :

Xms x nproc = max memory

Note :Make sure that your application tier memory has that much free memory available.

For example if you have 6 nproc and 256 for Xms,

That means we need 256x6 which is 1536 So we need to increase Xmx to Xmx1536

Meaning :

In $INST_TOP/apps/SID_HOSTNAME/ora/10.1.3/opmn/conf/opmn.xml

server -verbose:gc –Xmx1536M -Xms256M -XX:MaxPermSize=256M -XX:NewRatio=2-XX:+PrintGC TimeStamps

Do not run autoconfig just yet just bounce all application tiers.

After you test and you are happy with the outcome you can make these changes in the context file then ran autoconfig to make the changes permanent.

JVM: Guidelines to setup the Java Virtual Machine in Apps Ebusiness Suite 11i and R12 (Doc ID 362851.1)

Number of JVMs:

1) For OACoreGroup:

Assumption: eBusiness Suite is running in a 2-tier environment (middle tier in a separate machine)

- Start witn no more than 100 active users per JVM/OC4J instance.

- Start with 1 active JVM/OC4J instance per CPU core, though newer/faster chip families may support more than 1 JVM/OC4J instance per CPU core, depending upon threading, memory, I/O capabilities, etc. Confirm with appropriate hardware vendor for best results.

- Watch out for available memory (make sure that you have enough memory to run all the configured JVMs/OC4J instances without swapping)

Note: Each 'core' in a multi-core system is considered to be a separate CPU. For example, a dual quad-core chip would be the same as stating 2 x 4 x CPU or 8 CPUs.

In regards to hyper-threading cores, “virtual CPUs,” etc., in theory the same thing applies, but in some cases it may not equate to the exact same as a separate core. One could tune greater then a single CPU, but not treating the same as two CPUs, four CPUs, etc., depending upon the chip architecture. Confirm with appropriate hardware vendor for best results.

2) For FormsGroup:

For the forms servlet, the actual JVM/servlet usage is minimal, and a single JVM can normally handle up to 100-250 forms users.

Note: that depends on the type of forms. For more complex forms, those numbers are likely to be substantially lower

Notes:
a) The number of jvms (oc4j in R12) is configured by the autoconfig variables s_oacore_nprocs, s_disco_nprocs, s_forms_servlet_nprocs (11i), s_forms_nprocs (R12) and s_xmlsvcs_nprocs.
(these variable should be updated in the $CONTEXT_FILE using the autoconfig editor from OAM)
b) In 11i, those changes are made in the $IAS_ORACLE_HOME/Apache/Jserv/etc/jserv.conf file, while in R12 in the $ORA_CONFIG_HOME/10.1.3/opmn/conf/opmn.xml

Heap Configuration:

1) For OACore, start with the following configuration:

For R12.0 and 11i:

-Xmx512M -Xms256M -XX:MaxPermSize=128M
-XX:NewRatio=2 -XX:+PrintGCTimeStamps

For R12.1 and higher:

      -Xmx1024M -Xms512M -XX:MaxPermSize=256M
      -XX:NewRatio=2 -XX:+PrintGCTimeStamps

     Also, ensure you add the following parameter to the DBC file:

     JDBC\:oracle.jdbc.maxCachedBufferSize=262144

Ex:

From :-

oacore_jvm_start_options -Xmx1024M -Xms1024M

oacore_jvm_stop_options -Xmx1024M -Xms1024M

<oacore_nprocs oa_var="s_oacore_nprocs">1</oacore_nprocs>

[oracle@ svrprdsa1 admin]$ ps -ef|grep s_oacore_nprocs $CONTEXT_FILE

<oacore_nprocs oa_var="s_oacore_nprocs">1</oacore_nprocs>

TO :-

oacore_jvm_start_options -Xmx1024M -Xms512M

oacore_jvm_stop_options -Xmx1024M -Xms512M

<oacore_nprocs oa_var="s_oacore_nprocs">2</oacore_nprocs>

[oracle@svrprdsa1 admin]$ ps -ef|grep s_oacore_nprocs $CONTEXT_FILE

<oacore_nprocs oa_var="s_oacore_nprocs">2</oacore_nprocs>

Adjust the heap sizes accordingly to minimize garbage collection frequency and user pause times due to full garbage collections.

In JDK 1.6, the JVM detects that you have a server class machine (2 or more CPUs with 2GB or more memory), and will automatically enable Parallel Throughput Garbage Collector. The number of GC threads defaults to the number of CPUs on the machine. If you are running multiple JVMs on the same machine, or if your machine has more than 2 CPUs, to avoid the GC threads to be overly active you should reduce the number of GC threads by using:

-XX:+UseParallelGC -XX:ParallelGCThreads=2

In most cases, using 2 GC threads should be sufficient. If you are using heap size of over 1GB, you can experiment with 4 GC threads and see if it gives you better performance.

2) If using Forms in Servlet mode, the following configuration for FormsGroup should be enough for most of the cases:

-Xmx256M -Xms128M -XX:MaxPermSize=128M -XX:NewRatio=2

Notes:
a) The heap is configured by the following autoconfig variables:
    11i: s_jvm_options, s_forms_jvm_options
    R12: s_oacore_jvm_start_option, s_forms_jvm_start_options,
    (these variable should be updated in the $CONTEXT_FILE using the autoconfig editor from OAM)
b) In 11i, those changes are made in the $IAS_ORACLE_HOME/Apache/Jserv/etc/jserv.properties file, while in R12 in the $ORA_CONFIG_HOME/10.1.3/opmn/conf/opmn.xml

Additional Recommendations:

1) R12 comes with Forms configured in servlet mode by default, because it is easier to setup if you need features like SSL. However, Forms in servlet mode may have some performance degradation, depending on the network capacity. For this reason, if performance is a concern, you may consider run Forms in socket mode, as it is more efficient than servlet mode.

2) Although the setup of those parameters can be temporarily done manually changing (jserv.conf and jserv.properties in 11i; opmn.xml in R12), the correct way to update those parameters is using the context editor, update the variables s_oacore_nprocs and s_forms_servlet_nprocs, and then run autoconfig.

3) Oracle Development recommends to be on the last ATG rollup patch, which is currently ATG-rollup7 (Note.783600.1).

4) Make sure to have the following setting in the jserv.properties (11i) or oc4j.properties file (R12) file:
wrapper.bin.parameters=-DLONG_RUNNING_JVM=true

If there is any entry in jserv.properties setting -DCACHEMODE, either comment it out or remove that entry:
#wrapper.bin.parameters=-DCACHEMODE=LOCAL

5) Check also recommended patches for Performance issues in:
Note 244040.1 - Oracle E-Business Suite Recommended Performance Patches

6) AIX accepts only the parameters "-Xmx" -Xms". The reminder of the parameters should not be used on those platforms. More
More info about JDK parameters on AIX can be found at
http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=%2Fcom.ibm.java.doc.60_26%2Fvm626%2FJ9%2FGC%2Fxmxoption.html

++++++++++++++++

Increasing Number of JVMs Allocated to oacore Process Causes Login Problems (Doc ID 731115.1)

monitor_jdbc_conn.sql - Script to monitor JDBC connections in Apps eBusiness Suite (Doc ID 557194.1)

1454792.1 & 1061482.1

appsdba4all

Wednesday, January 14, 2015

The Java.lang.OutOfMemoryError: Java Heap Space Error which means that the JVM ran out of memory

Friday, January 9, 2015

APP-PAY-06882 and APP-FND-01388 Errors When Executing Quickpay