wcf - WCF/CaSTLe 内存泄漏

Question

我们的 MVC3 网络应用程序和 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 遍历内存转储，以找到持有 SlidingWindow 实例引用链的实际 GC 根目录。

PS:不要试图使用生命周期更长的范围(请求或消灭想法，单例)来尝试解决这个问题。解决方案是妥善处理代理实例。我很难发现这一点......;-)