4

I recently wrote a small service that handles high amounts of throughput (on the order of 60+ million requests per day) and it is encountering memory issues. At first, I looked through all of the usual suspects convinced that it had to be something I wrote as opposed to something to do with the very useful very performance-oriented ServiceStack libraries. Upon using windbg to !dumpheap -stat on the production server, however, I discovered to my surprise that the vast majority of objects in memory were System.WeakReference types with !gcroots pointing to ServiceStack's Funq container.

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

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

I read elsewhere that the System.WeakReference objects are often inserted by .NET in rare instances due to the Visual Studio compiling the binaries having the "Edit and Continue" debugging option on, but turning it off in my VS has no effect (presumably because the SS binaries are already compiled and just referenced in my project).

Has anyone else ever had this issue?

welegan
  • 3,013
  • 3
  • 15
  • 20

1 Answers1

2

WeakReference is used in Funq to track IDisposable's that's stored in a WeakReference Stack of disposables as seen here. Basically Funq tracks every IDisposable WeakReference created so they can all be disposed of when the Container is disposed.

I would first look at whether you could reduce your use of IDisposable instances (e.g. using more singletons), otherwise try modifying the Funq source code to use Stack<IDisposable> instead of a Stack<WeakReference> and let me know if this resolves your issue, if it does I can include an opt-in option in ServiceStack to use Stack<IDisposable> instead of Stack<WeakReference>.

mythz
  • 141,670
  • 29
  • 246
  • 390
  • Thanks for the reply! The thing that is really confusing for me is that I am not using Funq to store any objects at all. My service just has a static property that I'm using (I know, IoC is great, etc.) But I was wondering why it would allocate to the IDisposable stack if I'm not even registering anything with it? – welegan Jan 16 '13 at 00:13
  • Ok it shouldn't be doing that, I'll look into it and make sure it doesn't track IDisposable's when using an external IOC. – mythz Jan 16 '13 at 00:36
  • Thanks for investigating. I just changed our service to inherit from RestServiceBase, and memory usage is lower than when it was using the new Service base class. I know it's deprecated, but was there any change to Funq behavior between the two? I only ask because an earlier service we wrote (albeit with less traffic) using ServiceStack 3.9.28 has been running fine for weeks, so we tried using the old API with the memory-leaking service. – welegan Jan 16 '13 at 02:31
  • Only that the `Service` base class has more dependencies already registered for you. Try instead implementing your service using the empty `IService` interface instead, which doesn't have any deps. – mythz Jan 16 '13 at 10:02
  • I updated our service to inherit IService instead of the Service base class, and I'll report back later today about whether or not that solves the memory issue. – welegan Jan 16 '13 at 15:42
  • It's been 12 hours and the memory usage has not been as high as it used to be, so it seems that some dependency in the Service base class was causing the WeakReferences to get out of hand. Thanks for the answer Mythz, and for maintaining such a useful tool. – welegan Jan 17 '13 at 02:44
  • FYI: I've [committed a fix](https://github.com/ServiceStack/ServiceStack/commit/fb63dc03a016e5b56944ea99a25252767a3e6ea0) that no longer tracks WeakReferences of all disposables by default. Will be available in the next release of ServiceStack on the weekend. – mythz Jan 23 '13 at 15:58