EF 6.1.3 - Devart leaking SafeHandles on slow Connections
Posted: Fri 26 Jan 2018 13:39
Hi guys,
I recently encountered a weird problem which resulted in an OutOfMemoryException within our application.
Context: For migrating data from one application version to another (and circumvent some issues with EF migrations), I basically dump all database contents to XML and import said data in the new version. This is done table by table, using a dedicated EF context for each table to be able to dispose the context from time to time.
So far so good, worked for about two years without problems. Now a client contacted me, complaining about OutOfMemory crashes when exporting. It took some time with manual tests and memory profiler to reproduce the issue. Apparently it takes a slow (or just bad) connection to an oracle server to cause the memory leak. With a fast connection, all works well. When using a MS SqlServer database, no issues.
Here a memory usage graph:
The actual crash happened around the 2:05:00 mark where the private bytes peak at about 1.5 Gigabytes. I was not around for the crash because... well... 2 hours.
I ran the export again, just for half an hour, and took some snapshots to find the culprit. Here a screen shot showing loads of SafeCapiKeyHandles and SafeCspHandles:
Instance Categorizer:
And the instance list for SafeCapiKeyHandle:
As you can see, there are just a few SafeHandles of generation 8, all the others are dependant on them but awaiting to be collected. When running the export for a longer time, there are always about 3-5 handles with increasing generation level, enmassing a huge amount of dependant handles.
In contrast when using a good connection, the SafeHandles look fine:
I found a way to mitigate the issue short term, by inserting forced GarbageCollects on all generations in my code and enabling LargeAddressAware for the application. Here the SafeHandles in about the same amount of runtime:
Still too many handles for my taste but at least they are kept within the lower 4-digits. This is keeping the actual problem manageable rather than solving it.
I can reproduce the issue with dotConnect for Oracle 9.2.187 and 9.4.348, accessing Oracle 12c Enterprise v12.1.0.2.0 on Unix server, client software running on Windows 7 Pro, Windows Server 2012 Enterprise, Windows 10 Pro, .Net Framework 4.5.2 and 4.6.
I am not sure if this issue is due to the slowness of the connection, package loss, connection encryption or something different entirely. But I am wondering if someone else has a similar problem and it would be much apreciated if you devart guys had a look at it. Sorry for the rather small amount of information, my resources to track this further are limited.
Best regards
Felix
I recently encountered a weird problem which resulted in an OutOfMemoryException within our application.
Context: For migrating data from one application version to another (and circumvent some issues with EF migrations), I basically dump all database contents to XML and import said data in the new version. This is done table by table, using a dedicated EF context for each table to be able to dispose the context from time to time.
So far so good, worked for about two years without problems. Now a client contacted me, complaining about OutOfMemory crashes when exporting. It took some time with manual tests and memory profiler to reproduce the issue. Apparently it takes a slow (or just bad) connection to an oracle server to cause the memory leak. With a fast connection, all works well. When using a MS SqlServer database, no issues.
Here a memory usage graph:
The actual crash happened around the 2:05:00 mark where the private bytes peak at about 1.5 Gigabytes. I was not around for the crash because... well... 2 hours.
I ran the export again, just for half an hour, and took some snapshots to find the culprit. Here a screen shot showing loads of SafeCapiKeyHandles and SafeCspHandles:
Instance Categorizer:
And the instance list for SafeCapiKeyHandle:
As you can see, there are just a few SafeHandles of generation 8, all the others are dependant on them but awaiting to be collected. When running the export for a longer time, there are always about 3-5 handles with increasing generation level, enmassing a huge amount of dependant handles.
In contrast when using a good connection, the SafeHandles look fine:
I found a way to mitigate the issue short term, by inserting forced GarbageCollects on all generations in my code and enabling LargeAddressAware for the application. Here the SafeHandles in about the same amount of runtime:
Still too many handles for my taste but at least they are kept within the lower 4-digits. This is keeping the actual problem manageable rather than solving it.
I can reproduce the issue with dotConnect for Oracle 9.2.187 and 9.4.348, accessing Oracle 12c Enterprise v12.1.0.2.0 on Unix server, client software running on Windows 7 Pro, Windows Server 2012 Enterprise, Windows 10 Pro, .Net Framework 4.5.2 and 4.6.
I am not sure if this issue is due to the slowness of the connection, package loss, connection encryption or something different entirely. But I am wondering if someone else has a similar problem and it would be much apreciated if you devart guys had a look at it. Sorry for the rather small amount of information, my resources to track this further are limited.
Best regards
Felix