Re: Memory leak when using OleDb




"Arild Bakken" <arildb_@xxxxxxxxxxx> wrote in message
news:ORfrlg5bGHA.2188@xxxxxxxxxxxxxxxxxxxxxxx
Hi,

I'm facing a problem where using the System.Data.OleDb library to read
binary data from a SQL Server 2000 database. The sample code:


OleDbConnection objConn = new OleDbConnection("Provider=SQLOLEDB;Data
Source=SQLSERVERNAME;Initial Catalog=pubs;Integrated Security=SSPI");
objConn.Open();

OleDbCommand objCmd = new OleDbCommand("SELECT logo, pr_info FROM pub_info
WHERE pub_id = ?", objConn);
objCmd.CommandType = CommandType.Text;
objCmd.Parameters.Add("@pubid", 736);

OleDbDataReader objReader = objCmd.ExecuteReader();
objReader.Read();
objReader.Close();

objCmd.Dispose();
objConn.Close();
objConn.Dispose();


Running this in a loop, say 2000 times you'll see that the memory of the
process keeps growing and growing (on my computer it passed 128MB). The
data retrieved is pretty small (643 byte logo and 64KB info) and running
the same type of code against a database with, say a 5MB word document
will dramatically eat up the memory. I tested that, and the process ate
10MB of memory every second (it carried out two requests per second) so it
would seem the entire blob of data retrieved was leaked...

If, however, I update the code to use the System.Data.SqlClient library
instead with its SqlConnection, SqlCommand and SqlDataReader objects (and
modify the select statement and connection string) then the leak is gone.

Does anyone have any idea what I'm missing here? Now, I could change all
my code to use SqlClient instead, but I really can't believe that there is
such a tremendous leak in the OleDb libraries of .NET nor in the OleDb
native libraries so I'm guessing I've missed something on the Close() /
Dispose() requirements - and if that's the case I might end up with the
same problem with the SqlClient libraries later...

BTW - this is .NET 1.1 and sample has been run on Win2K SP4 with all
patches, and on WinXP SP1 with all patches.

Any tips as very welcome.



There is a persistent difficulty with COM interop (OleDB is COM). .NET code
accesses COM objects throught Runtime Callable Wrappers. These wrappers are
finalizable .NET objects that hold the interface pointers to COM components.
When the Runtime Callable Wrapper is Finalized it will decrement the
reference count for the COM component. When the reference count for the COM
pmponent goes to 0, it will be destroyed and its memory freed.

The problem comes in with the Garbage Collector. These Runtime Callable
Wrappers are very small objects, and thousands of them can be created
without the Garbage Collector noticing that a ton of memory is being
allocated.

This memory will be released, eventually, after a full GC. This is better
in .NET 2.0, but I suspect that's the reason the memory footprint of your
application is higher using the OleDb provider than the SqlClient.

David


.



Relevant Pages

  • Re: W3WP memory usage
    ... You may be correct regarding the libraries using the lion's share of memory. ... > I am quite aware that Sharepoint files are stored in the database. ... >>> public class SPVersion ...
    (microsoft.public.sharepoint.portalserver.development)
  • Re: Will a large library cause WMP10 to slow system to a halt?
    ... 704 Megabytes Installed Memory ... of case likely would slow nearly everything down - not just the WMP. ... I have 2 250 Gb drives in a RAID 1 ... If you don't use libraries, how do you play music in WMP? ...
    (microsoft.public.windowsmedia.player)
  • Re: [RFC 0/3] Recursive reclaim (on __PF_MEMALLOC)
    ... Once the memory requirements of a userspace daemon ... Yes, and also inspect the code to ensure it doesn't violate mlock_all by execing programs, dynamically loading libraries, etc. ... In nbd-server, there's no dlopen, and I do not currently plan to add ... Avoiding glib is a good start. ...
    (Linux-Kernel)
  • Re: Dlls,memory allocation
    ... quite a few dlls and execute. ... be no dynamic memory in the libraries.. ... In that case, the allocation /freeing will ...
    (comp.lang.c)
  • Re: process size
    ... > memory. ... I always believed that shared libraries also save space in RAM:) The ... process has to map the code into its memory. ... Shared libraries allow to map single physical memory page ...
    (comp.unix.programmer)