实体框架DataContext不会在IISWorker进程内存泄漏中卸载内存吗?

时间:2017-10-29 17:34:28

标签: entity-framework memory-leaks asp.net-mvc-5

我有一个用MVC 5 + Entity Framework编写的Web应用程序。

我注意到,对控制器的每个请求,访问EF数据,服务器内存都变得严重而且从未发布。

让我们说,我开始使用300MB内存,经过50次请求后,这个过程已经接近1.5GB。

使用语句

附上DB上下文
using (var ctx = new MyEntitiesContext)
{
   var list = ctx.Answers.ToList();
   return list;
}

//此时我希望上下文被释放,内存被释放,   但这种情况不会发生,不会发生这种情况。

添加实体也是如此......

请帮忙吗?

1 个答案:

答案 0 :(得分:0)

上下文本身不会占用大量内存,如果使用using()块,则应该将其处理掉。但更大的问题是返回实体列表。服务器将分配内存来为请求提供服务,并且在请求完成后不会释放该内存,数据将进入垃圾回收,但分配给IIS的保留内存不需要锯齿状回落。问题在于它确实表明单个请求能够很快地需要大量内存。

如果这是服务器回调,请考虑定义仅针对您要显示的数据的视图模型,然后选择()来自实体的数据并返回视图模型列表。对于Web API方法也是如此,定义DTO只返回所需的数据。

</body>

从性能和内存使用的角度来看,返回实体的效率非常低,如果您尝试使用DbContext范围之外的任何引用,则很容易遇到延迟加载问题。 (如果您在范围内引用它们,则会出现性能问题)

还要确保使用.Where()子句过滤数据以避免加载太多行,并考虑在可能需要考虑支持行限制或分页的情况下数据大小可能显着增长的情况,以避免出现服务器停止运行,因为最终有2M答复记录,任何数量的用户都有能力请求所有这些记录。

除此之外,检查每个请求创建的多个上下文,因为这确实有性能成本。我建议阅读像Autofac这样的IoC容器,因为它可以集成到MVC中,并且可以为您管理DbContext或工作包装单元的范围,以确保每个请求只创建一个实例。