WCF / Castle的内存泄漏

Question

我们的 MVC3 Web 应用程序和 WCF 数据层服务之间存在内存泄漏问题。

我相信问题出在 WCF 方面，尽管无法追踪。我搜索了网络和这些论坛，但无法找到原因。任何帮助将不胜感激！

所以 - 最初的症状是与后端相关的 w3wp 进程的大小不断增长。我们可以看到，每次从调用服务的 Web 应用程序进行简单调用时，它都会以可变的数量增长（数量级 100kb）。

针对应用运行 Jetbrains 内存配置文件，我们可以看到

System.ServiceModel.Channels.TransmissionStrategy.SlidingWindow 

无疑是罪魁祸首。在应用程序启动时，有 4 个对象实例化了少量内存（占总数的 6.4%），在轻度使用后增加到 > 200 个对象，约占总数的 50%。持续使用将其推向 100%。我以前从未听说过这个，但是一些谷歌搜索表明它（除其他外）用于与 WCF 层之间的数据传输。

我目前的想法是正在创建进程，但从未正确释放。我们的服务是从 Castle 创建的，并从 Web 端注册为：

public static IWindsorContainer RegisterWcfService<TS, TI>(this IWindsorContainer container)
 where TI : TS
 where TS : class
{
 container.Register(Component.For<TS>().ImplementedBy<TI>().Named(typeof(TI).Name)
     .Interceptors<LoggingInterceptor>()
     .Interceptors<ExceptionHandlerInterceptor>()
     .LifeStyle.Transient
     .AsWcfService(
        GetServiceModel<TS, TI>()
        ));

 return container;
}

正如其他线程中所建议的，我们正在使用

container.Kernel.ReleasePolicy = new NoTrackingReleasePolicy();

以确保正确释放组件。我们没有明确地处理我们的任何服务引用，尽管我相信以上内容就足够了。有人对我们的泄漏可能来自哪里有任何建议或建议吗？

Answer 1

不幸的是，手动管理 WCF 代理的处置是确保为垃圾收集释放内存和释放网络资源的最可靠方法。这个brief blog post 解释了一些导致 WCF 代理泄漏内存和网络资源的问题。由于您已经将容器配置为创建瞬态代理实例，因此您应该将服务调用逻辑包装成类似于本文中所示的模式。

如果这不能解决您的问题，您可能需要使用 WinDbg 遍历内存转储，以找到实际的 GC 根持有对 SlidingWindow 实例的引用链。

PS：不要试图使用更长寿命的范围（请求或消除思想，单身人士）来尝试解决此问题。解决方案是正确处理代理实例。我很难找到这个... ;-)