8

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

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

在此处输入图像描述

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

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

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

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

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

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

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

4

2 回答 2

3

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

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

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

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

重构您的ActionFilter以避免使用所有控制器继承的某些“BaseController”也是一个好习惯。

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

确保您没有永久保存缓存变量，这些变量只会由应用程序池回收释放。

这只是提示，但有代码访问权限的工作将与您同在。:)

祝你好运！

于 2014-10-31T17:04:00.080 回答
0

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

于 2015-02-20T15:53:42.753 回答