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