Case Study: .NET Memory Leakage caused by Un-Released Oracle Objects


One Customer met an obvious .Net memory leakage issue in production environment. The memory usage quickly increased in peak time till application failed.


Captured the hang memory dump by DebugDiag 3 times with one hour time interval. By comparing the three dump files, we can see the String, Bytes, and OracleParameter are top 3 memory contributors.  String and Bytes can be related to some DB tables, and they are okay to be here because:


1. From the chart, the string/bytes size can be higher when the overall memory is lower. In short the application memory and the string/bytes size are not positively related in this case.

2. The total size of String+Bytes here is around 20% of the whole memory usage, plus there were no string concentrate  issue or huge tables in memory.


The spectacular findings are for OracleParameter and other Oracle objects, they  appeared  when the whole Memory usage was top:




Look at dump, the number of their instances are very  high:


MT             Instances    Obj Size (one Level)         Type

0244724c    87864         10470196 Oracle.DataAccess.Client.OracleParameter

02446324    20536         3010608    Oracle.DataAccess.Client.OracleCommand

024456f4    18516          1751600    Oracle.DataAccess.Client.OracleConnection


Checked Oracle related documents, it is clear that those objects were required to explicitly call the Dispose method. For example:





    // Remove all parameters from OracleParameterCollection










This requirement  is a bit different form Developers' experiences on SQL .NET Provider, in which the Close method will take care object disposes thoroughly.


Verified customer's code, there is no code statement to call Dispose for Oracle objects.


After customer modified the code per Oracle Development Guide, this type memory leakage issue went away.




Freist Li  from APGC DSI Team




Comments (0)

Skip to main content