TROUBLESHOOTING STEPS: Performance issues, Forms application, Reports, JVM Controller

1. Performance issues related to the size of the frmweb processes when executing RUN_REPORT_OBJECT()  (RRO) from Forms or running Forms that contain imported java.

If your Forms application is making even moderate usage of the RRO call to execute Reports from Forms, then you should configure a JVM Controller to decrease the size of the frmweb process.  See Note 1277681.1 Preventing Forms 11g Memory Jump after RUN_REPORT_OBJECT by Using a JVMCONTROLLER (JVM Pooling)

Settting up a JVM Controller in this case will prevent java libraries from being attached to each frmweb process making the RRO call and decrease the resources associated with the frmweb process significantly.  Here as a UNIX example using the "pmap -x <pid>" command:

RRO frmweb process size without JVM Controller:
total kB         2,447,192
RRO frmweb process size with JVM Controller implemented:
total kB          125,076

Note that the first number is not as bad as it seems as frmweb processes will share the associated binary libraries amongst them. However, you can see that adding the JVM Controller significantly reduces the frmweb process size which allows more frmweb sessions with less resources.  Note also that frmweb sizes may vary across platforms and are totally dependent on the size of the associated Form or Forms and what the application is doing. A reasonably simple form may result in a frmweb process of 12 - 25 mb.  frmweb proccesses for complex forms can consume 100-200 mb.

JVM Controllers can also reduce memory consumption of frmweb processes if imported java has been used in the Forms application.  The Java Importer enables you to automatically generate PL/SQL packages and procedures that allow you to create and use Java objects directly in your forms applications, all via the PL/SQL language facilities provided by Oracle Forms and the runtime services provided by the Oracle Forms Server.   The developer(s) of your Forms application can tell you if imported java is being used in the application.  Another way of determining if imported java is being used is to closely view the objects listed when using the "pmap -x <pid>" command.  If you see java related objects such as:

libjvm.so
libjava.so

and you are not using RRO then imported java is being used and JVM Controllers should be considered. 

2. Spinning frmweb processes taking large CPU resources.

Another factor that can contribute to performance issues are spinning frmweb processes that are consuming large amounts of memory or CPU resources; in some cases they can take up a considerable portion of CPU. There are a number of causes for this:

a.  Users closing the browser instead of gracefully exiting the Form.

User education and implementing a javaScript warning as listed in Note 605327.1 can prevent this.

b. An application that is doing an extremely resource intensive query/search can cause large frmweb processes.

This should be examined as a possible cause and remedied programmatically if the case.

c. A coding problem in an application.  Infinite loops will certainly cause this. 

d. A product defect.  In certain cases the Forms exception handler can fail and cause frmweb processes to hang.  In cases like this setting FORMS_ABTERM_CLEANUP can sometimes resolve the issue.  See Note 1494442.1

3. WLS Managed Server Related JVM Settings

The default values for the minimum and maximum java heap size for WLS_FORMS can be seen in the DOMAIN_HOME/bin/setDomainEnv file.  Normally, these are 256m and 512m respectively.  For most moderate sized Forms applications these are sufficient to run 250 to 400 Forms sessions on a single Forms Managed Server.  Of course these numbers will vary greatly depending  upon the complexity of the Forms application and the machine resources available.

Should it be determined that more Java heap memory is needed, then consider incrementally modifying the maximum heap (Xmx) in the setDomainEnv file and testing to determine the ideal setting for your environment.  See Note 1088413.1 .  Be cautious because it is possible to increase the heap too large which could take memory resources from other needed server functions.

If it becomes obvious that increasing the Java Heap does not improve performance then consideration should be given to:

a. Creating another Forms Managed Server on the same machine.  See Note 989118.1.

b. Creating another Forms Managed Server in the same Domain/Forms  Cluster on another machine using  the ORACLE_HOME/bin/config.sh "Expand Cluser" option.

4. Verify there are no problems with the installation.

a. Verify that the JDK used for the  WLS installation matches the FMW installation architecture.  32 bit JDK should only be used with 32 bit FMW Forms/Reports installations.  64 bit JDKs should only be used with 64 bit FMW Forms/Reports installations.  The latest RDA will display this information.

b.  JRockit is not supported with Forms/Reports installations.

c. On windows 64 bit it is possible to install WLS by simply clicking on the WLS jar file.  This should NOT be done and can cause java related limitations.  The correct JDK for your product version should be in the PATH and WLS should be installed using the appropriate java -jar syntax.

See Starting .jar installation Programs in Graphical Mode.

5. Modifying Oracle HTTP Server (OHS ) Parameters

In the majority of cases, there is no need to modify default OHS settings.    However, if it is desired to look into this, please see the section entitled "HTTP tuning Section" of Note 294749.1.

6.  Verify that the Performance Pack (Native I/O) is turned on for WLS.

This is turned on by default and should not normally be turned off.

See Note 1099353.1 How To Enable Performance Pack (Native I/O) On WebLogic Server

From the WLS Console you can determine if Native I/O is enabled.  Also, the <Managed Server>.log will  show if it is enabled. For example, here is output from a WLS_FORM managed server :

.........<Info> <Socket> <machine name> <WLS_FORMS> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1408635759414> <BEA-000446> <Native IO Enabled.>

 7. If seeing the following "out of memory" error related to opmn:

opmnctl status -l
Error occurred during initialization of VM
java.lang.OutOfMemoryError: unable to create new native thread
-bash-4.1$ opmnctl status -l
Error occurred during initialization of VM
java.lang.OutOfMemoryError: unable to create new native thread

This can be caused if the user account owning the WLS installation has "max user processes" (ulimit -u) set too low

The appropriate setting will depend on the number of processes on a particular machine running under that user account. However, situations have been reported where increasing the value of "max user processes" as follows have resolved this issue:

Original value -> 1,024       (Resulted in out of memory error)
Success value -> 29,995       (Resolved out of memory error)