Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<blockquote> <p>How can we programatically monitor the total memory used by application (managed + unmanaged).</p> </blockquote> <p>Use performance counters. In development/test easiest to use <code>PerfMon</code> to collect data in the background (using a data collection set) and then analyse the results in Excel or similar.</p> <p>If you need to continue with this in production usage, the application can read performance counters itself (using <code>System.Diagnostics.PerformanceCounter</code> and related classes).</p> <blockquote> <p>2) Would restarting the managed application also free up the unmanaged resources.</p> </blockquote> <p>Yes.</p> <blockquote> <p>3) Is there any other alternative approach. </p> </blockquote> <p>Yes: fix the problem.</p> <p>If the COM component or C++ library really leaks then those really need to be fixed (and if previously only used for short lived processes the leak could have been there for a long time).</p> <p>You might be hitting an interaction of the .NET managed heap and GC with use of the native heap. The managed GC runs when there is memory pressure (i.e. would otherwise need to get more memory for the process to complete an allocation). If the managed wrapper is not allocating memory (or not much) there is no cause for it to run the GC. When you reference COM components from .NET the reference is held in a native wrapper type, this wrapper frees the COM instance (by releasing the last counted COM reference) when it is collected by the GC.</p> <p>So if the GC does not run, then COM components will not be freed. All it takes is for COM instances to use a significant amount of memory and the total process memory commit can start to grow.</p> <p>There are three approaches (in decreasing preference):</p> <ol> <li>Use a method on the COM instance to free its memory use (e.g. releasing sub-objects) if it has one.</li> <li>Explicitly free the COM component instances when the managed code has finished with them&mdash;don't wait for GC&mdash;using <a href="http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.marshal.releasecomobject.aspx" rel="nofollow noreferrer"><code>Marshal.ReleaseComObject</code></a>.</li> <li>Force a GC.</li> </ol> <p>#3 is the simplest, and can be used to confirm this approach by forcing a full GC after a few hours of running (e.g. on a timer) and looking at the memory usage performance counters. If it is the case the proceed with #1 or #2.</p> <p>(This is essentially what happened in one of my first .NET projects, interaction of large amounts of unmanaged heap kept from being freed by a managed instance that wasn't been collected due to lack of managed memory pressure. Fix in that case was to add an additional method to the key COM component to release the objects it was holding.)</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload