PROBLEM:
The customer is having a problem with a memory leak within their JAVA application. Something this is not supported by Oracle Support though an SR.
INITIAL FINDING: they didn't use the free() when using the getclobval().
INITIAL SOLUTION: The customer changed their code to add in the free() and this reduced the leak but not all of it. 80-90% of the leak is gone
CURRENT ISSUE: We examined the latest heapdump and it still had the same signature as before, so we asked them to re-exam their code.
They couldn't find anything in the code so the next idea is to trace file JAVA application in hope to locating the memory leak and the location where they need a free() call.
JDK 1.6
Database 11.2.0.4
Red Hat Linux
Connection pooling
EXIT CRITERIA: Reduce the leak by 99-100%
--------MORE DETAIL-------------------------
By examining the headdump from an 11.2.0.4 database, we can see the leak and with the help of Oracle JAVA support initially identified it was related to customer Code NOT using the free() when using the getclobval() function.
---Description provided to the customer in the SR----------------
The Heapdumps from Production confirmed last week was that the Statements that we were focussing on were not triggering leaks from the same areas as what is being seen on your Production environment.
Even if we fix the issue seen on the statements included in the standalone testcase , it is not even a factor on your Production JDBC sessions.
As I had indicated in my earlier update , the Production connection pooled sessions are still showing close to 90% of its leaks in the "koh dur heap d" / "qmxtgCrBufClob" heaps.
Memory allocations from this heap is usually done when using :
a) getclobval() and a corresponding free() is not called.
b) XMLSERIALIZE
c) dbms_xmlschema.inPlaceEvolve
My preference would be to defer tracing ( being a last resort and a hit-and-miss approach ) and instead work with customer's Development Team to check if a code walkthrough reveals any other instances where getclobVals() are called and the corresponding free() is not called.
If it comes down to tracing , we can pick up a few top sessions and get Memory Snapshots before and after an hour's duration and hopefully we can find the statements of interest.
--------end-------------------------
The customer has NOT been able to locate the getclobval() and corresponding free() mismatch in their code. So they want to attempt to trace their application to pinpoint the segment of code causing the problem.
***** QUESTION for this group ********
We are at the last resort and need to trace to help the customer locate their leak. The JAVA support group pointed us to “How to Troubleshoot Native Memory Leak in Java Applications on Solaris (Doc ID 1320890.1)” and possibly using matrace and libnjamd tools. We are not JAVA experts and need some guidance or exact commands to help guide the customer on how best to trace their code.
Customer would like to test this tracing as soon as Tuesday 12/22.
Any help would be appreciated!
Message was edited by: Danv-Oracle