Weird garbage collection
-
I have a simple C# Windows Service which exposes some objects via remoting. These objects are also registered for COM Interop. I have a test web ASP page which creates the COM objects (which run remotely inside my service). Every thing has been running fine until we started stress testing. The service's memory increases until the box is on its knees whilst we run even a light test. However, here the strange bit, if I change the service process's start Main function to just sit and wait on a MessageBox.Show call instead of running as a service the test still runs perfectly well but the memory usage does not climb, it remains stable. Using perfmon viewing the CLR Memory/#bytes in all heaps we see a nice zig-zag pattern of allocs followed by garbage collection. When running as a service the perfmon graph just increases ever upwards. It seems as though garbage collection doesnt happen when remoting objects from a service? Any thoughts or similar experience?
-
I have a simple C# Windows Service which exposes some objects via remoting. These objects are also registered for COM Interop. I have a test web ASP page which creates the COM objects (which run remotely inside my service). Every thing has been running fine until we started stress testing. The service's memory increases until the box is on its knees whilst we run even a light test. However, here the strange bit, if I change the service process's start Main function to just sit and wait on a MessageBox.Show call instead of running as a service the test still runs perfectly well but the memory usage does not climb, it remains stable. Using perfmon viewing the CLR Memory/#bytes in all heaps we see a nice zig-zag pattern of allocs followed by garbage collection. When running as a service the perfmon graph just increases ever upwards. It seems as though garbage collection doesnt happen when remoting objects from a service? Any thoughts or similar experience?
I had a similar problem. It turned out to be the Com object. The GC tidies up whenever it likes unless you force it. I tried everything getting the handle of the com destroying implicitly, forcing GC nohing worked. Once the com instance was created there was no way in hell to destroy it. Funnily enough it wasn't even a custom com it was Microsoft's own!. It looks exactly the same problem as you are having. Never did cure it. Sorry could not help He who laughs last thinks slowest.
-
I had a similar problem. It turned out to be the Com object. The GC tidies up whenever it likes unless you force it. I tried everything getting the handle of the com destroying implicitly, forcing GC nohing worked. Once the com instance was created there was no way in hell to destroy it. Funnily enough it wasn't even a custom com it was Microsoft's own!. It looks exactly the same problem as you are having. Never did cure it. Sorry could not help He who laughs last thinks slowest.
We use System.Runtime.Marshal.Cantremembetthisbit.ReleaseComObject() which seems to clean up on the spot.