我们的MVC3 Web应用程序和WCF数据层服务之间存在内存泄漏问题。
我认为问题来自WCF方面,虽然无法追踪它。我搜索过网络和这些论坛,但一直无法找到原因。任何帮助将不胜感激!
所以 - 最初的症状是与后端相关的w3wp进程的大小不断增长。每次从调用服务的Web应用程序进行简单调用时,我们都可以看到它以可变数量级(100kb的数量级)增长。
针对应用程序运行Jetbrains内存配置文件,我们可以看到
System.ServiceModel.Channels.TransmissionStrategy.SlidingWindow
远远不是罪魁祸首。在应用程序启动时,有4个对象实例化了少量内存(占总数的6.4%),在温和使用后它上升到> 200件物品,约占总数的50%。持续使用将此推向100%。我以前从来没有听说过这个,但有些谷歌搜索表明它在(和其他事项)中用于与WCF层之间的数据传输。
我目前的想法是创建流程,但从未正确发布。我们的服务由Castle创建,并从网络端注册为:
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();
确保正确释放组件。我们并未明确处理任何服务引用,但我相信上述内容应该足够了。有没有人对我们的泄漏可能来自何处提出任何建议或建议?
答案 0 :(得分:4)
不幸的是,手动管理WCF代理的处理是确保释放内存以进行垃圾收集和释放网络资源的最可靠方法。这个brief blog post解释了导致WCF代理泄漏内存的一些问题。网络资源。由于您已将容器配置为创建临时代理实例,因此应将服务调用逻辑包装为与文章中所示类似的模式。
如果这不能解决您的问题,那么很多人需要使用WinDbg浏览内存转储,以找到保存SlidingWindow
实例的引用链的实际GC根目录。
PS:不要试图使用寿命更长的范围(请求或消灭思想,单身)来试图解决这个问题。解决方案是正确处理代理实例。我发现这很难......; - )