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

Question

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

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

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

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

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

  

红门ANTS探查器测试显示实体太多   正在创建框架元数据工作空间，从而导致大量额外的工作空间   要保留的对象映射和关联的SQL命令文本。有   也是特定存储库中myEntities的单个实例   包含MetadataWorkspace和InitializerMetadata缓存   在压力测试结束时包含351个条目。这351个条目   每个都有另一个myEntities副本，每个副本都有一个   MetadataWorkspace，每个都有数百个对象映射。

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

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

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

Answer 1

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

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

在ReadOnly情况下，您也可以使用Dapper而不是EF。

最后，但并非最不重要的是，使用纯ADO.NET，以获得更复杂的查询和最快的执行。

重构你的ActionFilters以避免使用某些＆＃34; BaseController＆＃34;所有控制器继承的都是一种很好的做法。

检查您的IDisisableable类是否真的被CG压制，采用.Dispose(bool)模式。

请确保您不会永久保留缓存变量，只会由应用程序池循环释放。

这只是提示，但是有了代码访问权限的辛苦工作。 ：）

祝你好运！

Answer 2

检查会话中是否存储了代理实体。另一方面，它不需要在Dispose()中明确调用DbContext。 请检查此http://blog.jongallant.com/2012/10/do-i-have-to-call-dispose-on-dbcontext.html#.U6WdzrGEeTw