FMW plays an important role in EBS 12.2 , as EBS 12.2 delivers Http services ,OAF and forms services through FMW.
That's why, time-to-time, a real diagnostics is required , especially for analyzing weird performance and hang issues on EBS OAF pages.
In this post, I will go through the things that can be done for debugging the Weblogic side, especially the managed server performance and stability.
Of course, when dealing with weblogic inside EBS, we directly check the managed server logs, admin server logs, Heap size configurations, managed server counts (whether it is aligned with the concurrent user count or not), connection pool limits and so on. On the other hand; these debugging activities that I will give you in this blog post, are a little more advanced. It is also needless to say that, these debugging activities require advanced skills on Weblogic and EBS administration.
Note that,I won't give the full instructions for these diagnostics activities. In other words; I will explain them very briefly.
Also note that, these activities are not fully documented, that's why they are not fully supported --the risk is yours.
Garbage Collector Debug: for getting a more elaborated GC info and checking the time passed for each GC event.
We can get this debug info using -XX:+PrintGCDetails and -XX:+PrintGCTimeStamps, jvm arguments.
Running technology stack inventory report: to collect the list of patches applied to all middle tier homes (besides Weblogic).. The output of this script may be used to identify unapplied performance patches.
Creating Java Stack Trace : Especially for getting info about hanging, blocking, spinning processes. These diagnostics are done by using the necessary command line arguments in server start arguments section of the related managed server (using WLS console)
We check the traces (find the relevant trace using "grep MODULE *.trc and/or "grep ACTION *.trc"
$ADPERLPRG $FND_TOP/patch/115/bin/TXKScript.pl -script=$FND_TOP/patch/115/bin/txkInventory.pl -txktop=$APPLTMP -contextfile=$CONTEXT_FILE -appspass=<appspassword> -outfile=$APPLTMP/Report_App_Inventory.html
Diagnostic Connection Leaks: for getting leak connection-related diag info, we use "How To Detect a Connection Leak Using Diagnostic JDBC Dumps (Doc ID 1502054.1)"
Create heap dump & thread dumps: Especially for getting info about an outofmemory problems.
--review -> How To Create a Java HeapDump in E-Business Suite (Doc ID 835909.1)
You add the following parameters to JVM startup parameters -> -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=<path>
Then you restart the relevant managed server and wait an outofmemory error to occur.
Note that a heap dump is written only on the first OutOfMemoryError.
You can also generate the heap dump by using jmap or jconsole..
--review -> How To Create a Java HeapDump in E-Business Suite (Doc ID 835909.1)
You add the following parameters to JVM startup parameters -> -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=<path>
Then you restart the relevant managed server and wait an outofmemory error to occur.
Note that a heap dump is written only on the first OutOfMemoryError.
You can also generate the heap dump by using jmap or jconsole..
Examples:
jmap -dump:format=b,file=<filename> <jvm_pid>
Launch jconsole --> attach to the java process --> and invoke operation dumpHeap() on HotSpotDiagnostic MBean
Note that, the generated trace file can be analyzed using 3rd party tools like Solaris tool jhat, IBM HeapAnalyzer, Eclipse Memory Analyze.
jmap -dump:format=b,file=<filename> <jvm_pid>
Launch jconsole --> attach to the java process --> and invoke operation dumpHeap() on HotSpotDiagnostic MBean
Note that, the generated trace file can be analyzed using 3rd party tools like Solaris tool jhat, IBM HeapAnalyzer, Eclipse Memory Analyze.
Creating Java Stack Trace : Especially for getting info about hanging, blocking, spinning processes. These diagnostics are done by using the necessary command line arguments in server start arguments section of the related managed server (using WLS console)
The related arguments are specified using the server start arguments section ->
Connect WLS console
Navigate to servers under EBS_domain_<SID> environment
Click on the managed server (ex:oacore_server1)
Click on Lock & Edit in Change Center
Click on Server start
Navigate to servers under EBS_domain_<SID> environment
Click on the managed server (ex:oacore_server1)
Click on Lock & Edit in Change Center
Click on Server start
Edit arguments (such as -XX:HeapDumpOnCtrlBreak)
So once the necessary argument is given to a managed server, we restart the managed server and use OS kill commands to generate these dumps.. (ex: kill -3 os_pid -- kill -3 - SIGQUIT - like ctrl-C but with a core dump)
--review -> How to create a Java stack trace on e-Business Suite ? (Doc ID 833913.1)
Once the error is reproduced we review the FMW logs -> 12.2 Ebusiness Suite - Collecting Fusion Middleware Log Files Note 1362900.1.
Consider increasing Stuck Thread timeouts : in case we have stuck threads.. We can increase the Stuch Thread Max Time using Weblogic console.
Connection Debugging: For JDBC connection debugging, we use Oracle E-Business Suite 12.2 Data Source Connection Pool Diagnostics (Doc ID 1940996.1).
DB level trace: We enable trace at db level -> "alter system set events '10046 trace name context forever, level 12';"
We reproduce the issue and turn it off "alter system set events '10046 trace name context off';"We check the traces (find the relevant trace using "grep MODULE *.trc and/or "grep ACTION *.trc"
Tracing Managed Server sessions : For diagnosing managed server related db activity, and for diagnosing inactive (not closed) managed server sessions.
Reference: On E-Business Suite 12.2 V$SESSION.PROCESS incorrectly reports EBS Client Process ID as '1234' (Doc ID 1958352.1)
Connect to Weblogic Console and then do the following;
Services > Data Sources > EBSDataSource > Configuration > Connection Pool
Set "System Property" as below
v$session.program=weblogic.Name [Take note of the initial value one is changing as one will need to reset it once the fix is delivered and applied.]
Lastly we restart oacore managed servers and monitor the database using a query like;
SQL> select program, process, machine, sql_id, status, last_call_et from v$session where program like 'oacore_server%';
Reference: On E-Business Suite 12.2 V$SESSION.PROCESS incorrectly reports EBS Client Process ID as '1234' (Doc ID 1958352.1)
Connect to Weblogic Console and then do the following;
Services > Data Sources > EBSDataSource > Configuration > Connection Pool
Set "System Property" as below
v$session.program=weblogic.Name [Take note of the initial value one is changing as one will need to reset it once the fix is delivered and applied.]
Lastly we restart oacore managed servers and monitor the database using a query like;
SQL> select program, process, machine, sql_id, status, last_call_et from v$session where program like 'oacore_server%';
