.NET MVC /實體框架應用程序中的內存使用率過高

我有一個相對較大的實體框架模型（大約300個表格），我預先生成視圖以提高查詢/應用程序的性能。.NET MVC /實體框架應用程序中的內存使用率過高

當應用程序處於最低負載下時，我會在6-7小時內逐漸增加應用程序內存消耗。達到約。 4GB，則應用程序池將重置並重復該過程。

enter image description here

圖1：顯示應用程序內存消耗超過8-9小時

本申請的過程中使用的存儲庫模式的變化，並確保我的ObjectContext的實例實例化重和銷燬在每個交易中最短的時間內是可行的。我還在所有存儲庫/接口上實現了IDisposable，以清理所有資源。

我曾經在內存分析器應用進行了廣泛的測試，如紅門螞蟻的個人資料，WinDbg中和他人，迄今無法確定內存問題的確切原因，但已經注意到以下：

紅色的門螞蟻探查器測試顯示，有太多的Entity 框架MetadataWorkspaces被創建，導致許多額外的對象映射和關聯的SQL命令文本被舉行。也是在特定存儲庫中的myEntities的單個實例，其中包含MetadataWorkspace，並且初始化者元數據緩存在壓力測試結束時包含351個條目。這些351條目每個都有另一個myEntities副本，每個副本都有一個 MetadataWorkspace，每個都有數百個對象映射。

我的核心解決方案的結構如下：

介紹 - ASP.NET MVC 3
業務 - 對象，的ViewModels，接口
基礎設施 - 實體框架模型
數據訪問 - ADO.NET直接數據訪問

如果anybod y能夠提供任何指針，我會非常感激。

來源

2013-08-16 Nick

我不太確定，沒有很好的看代碼，但通常當你處理內存泄漏和EF的快照跟蹤沒有被正確清除的症狀。你說你定期處理你的背景，但我會先仔細檢查一下。繼承人我的診斷表EF EF問題：http://blog.staticvoid.co.nz/2012/8/1/entity_framework_performance_cheat_sheet –

嗨盧克。這是一個很好的資源 - 謝謝你。我已經做了大部分工作（減去延遲加載的禁用），並想知道是否還有其他具體的信息可以幫助我解答問題？ – Nick

不太確定我瞭解您對ANTS分析器測試的評論。無論如何，我會嘗試重構該存儲庫。當myEntities引用自身時，除非您在子條目中使用虛擬關鍵字打破鏈條，否則最終會出現內存問題。 – B2K

我們自動假設問題是EF。可以，不可以。我們應該關注很多要點，而不僅僅是數據訪問基礎設施。

由於您僅使用EF來發布數據訪問，因此您可以使用簡單的.AsNoTracking()方法快速獲得改進。採用ServiceLocator來幫助你管理你的上下文池。

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

最後但並非最不重要的，使用純ADO.NET，用於更復雜的查詢和最快的執行。

重構您的ActionFilters以避免使用一些所有控制器繼承的「BaseController」也是一種很好的做法。

檢查您的IDisposable類是否真的被CG所壓制，採用.Dispose(bool)模式。

請確保您沒有永久保存緩存變量，只能通過應用程序池回收來釋放緩存變量。

這只是提示，但辛苦的工作將與你，有代碼訪問。 :)

祝你好運！

來源

2014-10-31 17:04:00

檢查是否有代理實體存儲在會話中。另一方面，不需要在DbContext中明確地呼叫Dispose()。檢查http://blog.jongallant.com/2012/10/do-i-have-to-call-dispose-on-dbcontext.html#.U6WdzrGEeTw

來源

2015-02-20 15:53:42 Perdom

.NET MVC /實體框架應用程序中的內存使用率過高

回答

相關問題