.NET MVC/Entity Framework应用程序中的内存使用率过高

Question

我有一个相对较大的实体框架模型(约300个表),我预先生成视图以提高查询/应用程序性能.

当应用程序处于最小负载时,我会在6-7小时内逐渐增加应用程序内的内存消耗.达到约.4GB,重置应用程序池并重复该过程.

图1:显示8-9小时内的应用程序内存消耗

此应用程序使用存储库模式的变体,并确保我的ObjectContext实例在每个事务可行的最短时间内重新实例化和销毁.我还在所有存储库/接口上实现IDisposable以清理任何资源.

我已经使用内存分析器(如Red Gate的ANTS配置文件,WinDbg等)对应用程序进行了大量测试,到目前为止还无法确定内存问题的确切原因,但是已经注意到以下内容:

Red Gate ANTS分析器测试表明,创建的Entity Framework元数据工作空间太多,导致需要保留大量额外的对象映射和相关的SQL命令文本.在包含MetadataWorkspace的特定存储库中还有单个myEntities实例,并且InitializerMetadata缓存在压力测试结束时包含351个条目.这351个条目每个都有另一个myEntities副本,每个副本都有一个MetadataWorkspace,每个都有数百个对象映射.

我的核心解决方案结构如下:

• 演示文稿 - ASP.NET MVC 3
• 业务 - 对象,ViewModels,接口
• 基础设施 - 实体框架模型
• 数据访问 - ADO.NET直接数据访问

如果有人能够提供任何指示,我将非常感激.

Answer 1

我们自动假设问题出在 EF 上。可以是，也可以不是。我们应该注意很多点，而不仅仅是数据访问基础设施。

发布数据访问后，由于您只使用EF，因此可以通过简单的.AsNoTracking()方法获得快速的改进。采用ServiceLocator来帮助您管理上下文池。

在只读情况下，您还可以使用Dapper代替 EF。

最后但并非最不重要的一点是，使用纯 ADO.NET 来实现更复杂的查询和最快的执行。

重构您的ActionFilters以避免使用所有控制器继承的某些“BaseController”也是一个很好的做法。

检查您的 IDisposable 类是否确实被 CG 抑制，采用该.Dispose(bool)模式。

确保您不会永久保留缓存变量，这些变量只会通过应用程序池回收来释放。

这些只是提示，但是拥有代码访问权限的您将面临艰苦的工作。:)

祝你好运！