調(diào)查實體框架核心中的內(nèi)存泄漏

不要讓內(nèi)存泄漏成為洪水

術(shù)語“內(nèi)存泄漏”和“ .NET應(yīng)用程序”不是經(jīng)常一起使用。但是，我們最近在一個.NET Core Web應(yīng)用程序中出現(xiàn)了一系列內(nèi)存不足異常。事實證明，此問題是由Entity Framework Core中的行為更改引起的，盡管最終的解決方案非常簡單，但實現(xiàn)該目標的過程既充滿挑戰(zhàn)又有趣。

該系統(tǒng)本身托管在Azure中，由Angular SPA前端和后端的.NET Core API組成，使用Entity Framework Core與Azure SQL數(shù)據(jù)庫進行通信。作為專門從事.NET開發(fā)的軟件咨詢公司，我們之前已經(jīng)編寫了許多類似的應(yīng)用程序。因此，內(nèi)存不足崩潰^[1]是無法預料的，因此我們立即知道這是需要認真對待的事情。使用Azure門戶中的指標，我們可以看到內(nèi)存使用率穩(wěn)步上升，然后突然下降：此下降是應(yīng)用程序崩潰。

修復之前?

因此，我們花了一些時間進行調(diào)查并逐步進行更改，以解決看似經(jīng)典的內(nèi)存泄漏問題。.NET泄漏的常見原因是未正確處理某些問題，在我們的案例中很可能是EF Core數(shù)據(jù)庫上下文。因此，我們遍歷了源代碼，以尋找可能無法處理上下文的潛在原因。這變成了空白。

我們將Entity Framework Core升級到了最新版本，因為最近的更新包括各種內(nèi)存泄漏的修復程序和總體效率的提高。

我們還在使用的Application Insights版本中發(fā)現(xiàn)了可能的內(nèi)存泄漏（請參閱https://github.com/microsoft/ApplicationInsights-dotnet/issues/594），因此我們也對該軟件包進行了升級。

這些都不能解決問題，因此我們解剖了從Azure應(yīng)用服務(wù)中獲取的內(nèi)存轉(zhuǎn)儲（請參閱https://blogs.msdn.microsoft.com/jpsanders/2017/02/02/how-to-get-a-full-memory-dump-in-azure-app-services/）。

我們注意到，絕大多數(shù)托管內(nèi)存最終都由MemoryCache類使用。進一步深入研究表明，大多數(shù)緩存數(shù)據(jù)都是原始SQL查詢的形式。我們看到大量的根本上是同一查詢的事件被多次緩存，并且參數(shù)本身被硬編碼在查詢中而不是被參數(shù)化。

例如，與其像這樣緩存查詢：

SELECT TOP (1) UserId, FirstName, LastName, EmailAddress FROM Users WHERE UserId = @param_1

我們發(fā)現(xiàn)這樣的多個查詢：

SELECT TOP (1) UserId, FirstName, LastName, EmailAddress FROM Users WHERE UserId = 5

因此，我們進行了一些搜索，尋找可能與之相關(guān)的EF核心問題，并遇到了這個問題：https^[2]?:?//github.com/aspnet/EntityFrameworkCore/issues/10535^[3]。

關(guān)于這個問題的主題指出了這個問題：我們正在建立一個動態(tài)表達式樹，并使用它Expressions.Expression.Constant?來為where子句提供參數(shù)。使用常量表達式意味著Entity Framework Core不會參數(shù)化SQL查詢，并且是Entity Framework 6的行為更改。

我們到處都使用這個表達式樹，通過它的ID來獲取某些東西，這就是為什么它是一個很大的問題。

因此，這就是我們所做的更改：

// Before var param = Expressions.Expression.Parameter(typeof(T)); Expression = Expressions.Expression.Lambda<Func<T, bool>>(Expressions.Expression.Call(Expressions.Expression.Constant(valuesToFilter),"Contains",Type.EmptyTypes,Expressions.Expression.Property(param, propertyName)),param); // After var param = Expressions.Expression.Parameter(typeof(T)); // This is what we added Expression<Func<List<int>>> valuesToFilterLambda = () => valuesToFilter; Expression = Expressions.Expression.Lambda<Func<T, bool>>(Expressions.Expression.Call(valuesToFilterLambda.Body,"Contains",Type.EmptyTypes,Expressions.Expression.Property(param, propertyName)),param);

使用lambda表達式獲取表達式主體會使Entity Framework Core^[4]對SQL查詢進行參數(shù)化，因此僅緩存它的一個實例。

這是包括修訂版本在內(nèi)的一段時間內(nèi)的內(nèi)存使用情況。該版本以紅色標記，您可以看到差異很大。穩(wěn)定的內(nèi)存使用量從未超過200MB，而不斷攀升至超過1GB，然后發(fā)生崩潰。

修復后

最初進行調(diào)查時，真正的解決方案不是我們要注意的事情，而是通過檢查內(nèi)存轉(zhuǎn)儲并遵循證據(jù)我們最終到達那里。

從此調(diào)查中可以汲取的教訓是：

?內(nèi)存轉(zhuǎn)儲不會說謊-如果內(nèi)存泄漏，請先查看證據(jù)。?微軟已經(jīng)開放了EF Core的源代碼，所有問題在那里所有人都可以看到，對有需求的開發(fā)者來說非常方便。?簡單的代碼更改（在這種情況下為一行）可能會產(chǎn)生巨大的影響。

References

[1]?，內(nèi)存不足崩潰:?https://dzone.com/articles/what-causes-outofmemoryerror
[2]?https:?https://github.com/aspnet/EntityFrameworkCore/issues/10535
[3]?//github.com/aspnet/EntityFrameworkCore/issues/10535:?https://github.com/aspnet/EntityFrameworkCore/issues/10535
[4]?Entity Framework Core:?https://dzone.com/articles/entity-framework-core-30-and-sql-server-2019-perfo

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的如何分析EFCore引发的内存泄漏的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。