Questions needing answers :
Does the finalizer of the client side ServicedComponent call ServicedComponent.DisposeObject or Dispose?
How should destruction (release of memory) occur in the com server in relation to its usage in the client?
Basically - we are reaching a 2 gig limit on process size (memory) of the COM server as memory is not being released - is the solution to call explicitly call Dispose or use the using statement in the client?
You should definitely be calling either Dispose or ServicedComponent.DisposeObject on the client side. Microsoft says "It is preferable to use the Dispose design pattern rather than DisposeObject."
Exactly what is happening in COM+ will depend on a few things:
Is the application a Library or Server application
Is object pooling being used
Is JIT being used
If the calls are out of process then it is possible that lease times may come into play. Understanding Enterprise Services (COM+) in .NET is one of the best COM+ articles I've read but, since it was written in 2002, I wonder if it is still 100% accurate.
Related
I have a windows service written in C# using Selfhost technology that act like a little server that can handle some webservice's requests.
This server need to be run continuosly and actually has no policy of autoreload or explicit memory cleanup. In some tests i have noticed that after few days (a dozen) it become "instable" (what i mean is that it starts to fail accesses to DB and the memory allocated by process drammatically increase).
What i would to ask is if it's a known issue of this technology that need to be reload or a clean up memory afert certainly time, or if i need to investigate better in my code.
I smell of memory leak but it seems too strange because i only use managed objects.
I'm profiling memory use with ANTS Memory Profiler 7.0 and noticed that unmanaged memory use is ~193MB (~62%) for a console application that does little more than populate some DTOs from 10 million or so records.
The help text for unmanaged memory says:
The memory is assigned to the parts of the application that aren't running as pure .NET code. This includes the common language runtime itself, graphics buffers and any unmanaged data accessed through P/Invoke or COM+
Why might this figure be so high?
You will inevitable use unmanaged code when accessing a database. The interface to the engine is always code that's been around for a long time, predating .NET and wrapped by managed classes that provide the interop. True for, say, SQL Server and any provider that piggy-backs onto OleDb or ODBC.
These managed classes will always implement IDisposable so you can release the resources consumed by the native provider early. Forgetting to do so is very common and rarely noticed. Other than seeing the process running "heavy", seemingly consuming a lot of handles and unmanaged memory for no good reason. This will be especially the case when the garbage collector does not run frequently enough, something you can see with Perfmon.exe. So beyond not using Dispose, part of the problem can be that you don't do enough work with these DTO objects yet to get enough GC churn.
Review your code and ensure you use Dispose() and the using statement where required.
I have created a wcf service hosted in an exe process, and instantiated the client through class library which makes calls to the service. The class library is for a com addin to excel 2007 and the reason for the wcf service is so we don't use up excel in-proc memory when retrieving large amounts of data.
I've created the wcf service by implementing ClientBase with WSHttpBinding. I'm currently testing with a bare bone project and the only function is to return a message from the wcf service.
My question is regarding the memory usage in creating the wcf client and why it doesn't get released once it has been disposed. I've used address space monitor to monitor the memory usage and creating the binding and client uses around 70mb of committed memory.
Any information on wcf memory usage or GC for com dlls would be useful
Thanks
Heres a writeup:
http://www.danrigsby.com/blog/index.php/2008/02/26/dont-wrap-wcf-service-hosts-or-clients-in-a-using-statement/
Also Below is a thread similiar to yours that was posted awhile ago. It was answered by Igor Zevaka. Hopefully it could add more knowledge.
this.Dispose() doesn't release memory used by Form after closing it.
THats the way garbage collection in .net works. In all sorts of places it gives advantages, however in some it seems to be a hinderance. You may find - and i am stretchign things a bit - that when you dispose of 1 form and create a new instance it reuses that memory space. Although i doubt it.
Anyway ... garbage collection in .net is kinda interesting imo.
It will get cleaned up eventually ... just in an indeterminate amount of time.
I believe there is a command to force the garbage collection
Best Practice for Forcing Garbage Collection in C#
Of course its a bit like fight club - dont talk abou tit and if you do find it, you probably will wish you hadnt
GC.Collect();
iirc
Also dispose has an overload that takes a bool. When you call true on that it also goes through all its parts forcing them. There are several dispose patterns that are easily googleable. Juval Lowry goes into them in great depth in his components book.
We are using EWS Managed API which polls MS Exchange for new mail messages after a given interval. With each invocation of the polling call (PullSubscription.GetEvents()) - Microsofts API is failing to properly dispose the NetworkStream and causes memory to proportionately increase. This was previously discussed here, but never resolved. Using ANTS Profiler we were able to determine which objects were continuously growing in memory and isolate the issue.
Now that the issue has been isolated - is there a way to dispose of a NetworkStream created in an external API that we don't have a reference to? GC.Collect() doesn't seem to dispose it since it still has an active reference. What can we do to cleanup the dangling reference? Is there some wrapper we can use to force cleanup of their buggy SDK?
There is no way to force GC to release memory for a referenced object!
First of all I would suggest to contact microsoft itself for help with this bug.
Second, are you talking about "disposal" or just memory release? They are two totally different things. (IDisposable pattern, finalizers).
Third, can u just dereference the object that are referencing these objects?
Fourth, one possible solution can be to decompile with reflector the code that is giving you the issue, understand a way you can arrive to the fields that are keeping the referenced objects, use reflection in your code to access the private fields and put them to null.
Is a very dirty hack, but if you have no other way is the only thing i can think of. Do this only if you cannot go in any other ways.
The most easy way would be running the part the is interfacing the SDK into its own AppDomain and after your are done unload the AppDomain. This will cause all the memory allocated in the AppDomain to be freed.
But you will need add some work to your project since you can only interchange with an AppDomain the a MarshalByRef object or marked as serilizable.
This will also allow you to monitor the amount of memory consumed by the AppDomain. So you can create your AppDomain, run the buggy SDK in it and if it reaches a special limit of memory consumption you can unload it.
I know all the theories :
I know what is GC, when to call dispose, Finalise when it is getting called.
I would like to know, in your live project ..in which scenario have used all this.
I mean when the project
manager/client insisted you to
cleanup the memory ? When you find
any errors in the programs? Kind of
error messages or error logs? When
your program got crashed because of
unwanted memory? or any other
scenarios?
You should not care when and how GC is called. It is inteligent enough to know when to run and what objects to free.
You should also Dispose, either manualy or using "using" all objects, that implement IDisposable. You will then prevent many errors with un-managed resources, like files.
And if you are running out of memory, then there is something wrong with your algorithm or code itself. Manualy calling GC.Collect is heavily discuraged, especialy in production code.
As a rule of thumb, you need to implement IDisposable if you aggregate a disposable object, or if you hold on to an unmanaged resource. Cleanup is done differently for these two scenarios. Otherwise, keep it simple, don't litter your code with dotnetisms
Similar question here
Memory leaks cause crashed up servers. Cause and effect.
Ressource management is something you just havce to do. It is not 'my client insisted I free my memory'. It is simply good practice. Not all applications may crash and the user just restarts them - there is one or other server application out there.
If you start building your programming libraries, ressource management and concurrency should be your top priority, otherwise you will never be up to speed implementing any solution.
hth
Mario