Professional Documents
Culture Documents
Date :
July/08/2015
How To diagnose the "Root Cause" of OPP (java) consuming High CPU
This document helps if you find OPP (java) process hangs or spinning on your CPU (100%) which results in performance issue.
This result in either concurrent requests are slow or end with errors/warnings due to unavailability of OPP.
To diagnose the "Root Cause" of OPP (java) to consume High CPU perform the below steps. This document helps us to identify
the report (Template Code) which could be the potential cause for OPP to hang. Once you identify the Template Code, You need to take
the corrective action to fix as suggested at the end of this document.
DEMONSTRATION
STEP 1 (top/prstat)
1 25526
1 25544
1 25592
1 25600
1 25604
1 25610
1 25611
1 25612
1 25613
1 25614
1 25675
1 25676
1 25680
1 26005
1 26016
1 26019
1 26020
1 26021
1 26045
1 26046
1 26974
0.0 java
0.0 java
0.0 java
0.0 java
0.0 java
0.0 java
0.0 java
0.0 java
0.0 java
0.0 java
0.0 java
0.0 java
0.0 java
0.0 java
0.0 java
0.0 java
0.0 java
0.0 java
0.0 java
0.0 java
0.0 java
25526 1 1289 71.2 java <======= One of The thread ID that is taking High CPU time
25526 1 27867 70.6 java <======= One of The thread ID that is taking High CPU time
25526
25526
25526
25526
25526
25526
25526
25526
25526
25526
Note: - Find the analogous command (ps -eLo pid,ppid,tid,pcpu,comm.) for your platform which gives similar output.
3.
4.
5.
6.
7.
From the above output take out the string 6083684 which is the Concurrent Request ID.
You can now search for 6083684 in OPP log (i.e. FNDOPP488233.txt) again.
You should be able to locate the below lines which provides the Template code: CSTRINVR_XML which is the
"Root Cause" of OPP to hang or consume high CPU.
[6/29/15 10:28:18 AM] [OPPServiceThread1] Post-processing request 6083684.
6083684
8.
If required, pickup another thread ID (STEP 4) which consumes high CPU, and perform the diagnose the similar
way (step 1-7) that helps to identify another Template code: CSTRAIVR_XML
[7/1/15 4:09:29 PM] [488233:RT6124449] Starting XML Publisher post-processing action.
[7/1/15 4:09:29 PM] [488233:RT6124449]
Template code: CSTRAIVR_XML
Template app: BOM
Language:
en
Territory: US
Output type: RTF
Possible Action to fix :The Template code that you have identified could be either Standard (provided by Oracle) or Custom (designed by you).
1.
2.
Standard Code
Custom Code
II)
Ensure you applied all relevant XML patches as per (Doc ID 1138602.1). This helps to improve the performance of
both Standard as well as Custom Code.
As per the example given in the guide, its understood that CSTRINVR_XML & CSTRAIVR_XML are the "Root Cause"
of OPP (java) to consume high CPU. Now it is time to look for known solutions.
Since CSTRINVR_XML & CSTRAIVR_XML are Standard reports, you may search for known solution in My Oracle
Support Knowledge Base. If you do not find, you may seek help from Oracle Support.
But in this case, you may find below notes (when you search Knowledge Base) , and you should review them to
progress further.
1. For CSTRINVR_XML, you need to review
Intransit Value Report (XML Version) Slow Performance After Patch 14365559:R12.BOM.C (Doc ID 1626110.1)
Note: - It is recommended to take respective Support team (i.e. BOM, INV...) to consult before applying any patch (or)
changes, if you are not sure.
Custom Code - Tuning
1. Firstly, You may stop running the program that is using this template code for a day or so. This is to monitor & re-confirm if
the OPP hangs due to this concurrent request.
2. As it is a Custom Template code, you need to tune it yourself. Due to the nature of the customization, guidance for it may be
limited per (Doc ID 122452.1). However, you may use the below tips.
I.
II.
Ensure you applied available Patches for Oracle XML Publisher embedded in the Oracle E-Business Suite (Doc ID 1138602.1)
To optimize RTF template, ensure the rtf is made simple.
a. Use tables to control precisely where field data will be placed in the report.
b. Push expensive joins to the database Level instead performing at template level.
c. Many calculations are better performed in the data model.
d. Sorting large data sets is typically better performed by the database (indices, efficient disk sorting..)
e. Checking Data already sorted option in the Table Wizard will make use of group-adjacent which will not
re-sort the data.
f. Dont overcomplicate your templates. Use sub templates for re-use and complex code.
g. Use the full relative path for large data sets. i.e.
Instead of <?for-each: DEPT?>
use
<?for-each:/DEPT_SALS/DEPT?>.
III.
IV.
You may re-write the RTF afresh if possible. Sometimes re-write could be an easier option than tuning the existing one.
Also review Section 5 (Common RTF Optimization issues) of Note 1410160.1 - R12: Troubleshooting Known XML Publisher and EBusiness Suite (EBS) Integration Issues.
Conclusion
To resolve high CPU consumption by OPP, you need to collect all the above required details to isolate/identify the report
(Template Code) that caused the issue. Once you identify the Template Code you need to take corrective action to fix it. If its a
standard Template code, Please engage the respective Support team (i.e. BOM, INV...). If its a custom Template code, you need
to tune it yourself using above guidance.