ServiceStack Funq WeakReference Container Distribution

I recently wrote a small service that handles high throughput (about 60 million requests per day), and it faces memory problems. First, I looked at all the usual suspects who were convinced that this should be what I wrote, and not something in common with the very useful very performance-oriented ServiceStack libraries. However, using windbg to! Dumpheap -stat on the production server, I was surprised to find that the vast majority of objects in memory are types of System.WeakReference with! Gcroots pointing to a ServiceStack Funq container.

I don’t even use the IoC'ed data structure in my service, so I was wondering why this is happening? Am I initializing something incorrectly? My apphost initialization class simply calls the base constructor with assembly information and name, I don’t override the Configure method at all.

public SvcName() : base("SvcName", typeof(SvcName).Assembly) { } 

I read elsewhere that System.WeakReference objects are often inserted by .NET in rare cases because Visual Studio compiles binaries with the “Edit and Continue” option, but disabling it in my VS has no effect (presumably because that the SS binaries are already compiled and just listed in my project).

Has anyone else had this problem?

+4
source share
1 answer

The WeakReference is used in Funq to track the IDisposable , which is stored in the WeakReference Stack of disposables, as shown here . Basically, Funq tracks every IDisposable WeakReference created in such a way that they can all be deleted when the Container is placed.

First, I would like to see if it is possible to reduce the use of IDisposable instances (for example, using more singletones), otherwise try changing the Funq source code to use Stack<IDisposable> instead of Stack<WeakReference> , and let me know if it solves your problem, if possible, I can enable the inclusion option in the ServiceStack to use Stack<IDisposable> instead of Stack<WeakReference> .

+2
source

All Articles