原文：https://blog.markvincze.com/troubleshooting-high-memory-usage-with-asp-net-core-on-kubernetes/

ps：我不是死板翻譯原文的，盡量的通俗一點，如有不對歡迎指出，謝謝哈。

在生產環境中，我們把asp.net core api應用通過Kubernetes?部署在了Google Cloud (GCE—Google Container Engine)。我們發現大多數的組件（core應用）的內存使用率都不合理。我們把應用的內存限制設置成了500MB, 并且還發現了很多api應用實例因為超過了內存限制而被Kubernetes 不斷的重啟（應該docker設置了--restart）。

下面2張圖是我們其中的2個api，當Kubernetes重啟他們時，你會發現他們先是一直增長，然后到達了內存限制的點。

?針對于這個現象我們花了很多時間來調查這個issue，期間嘗試過通過抓dumps來分析，但是并沒有發現問題所在。

我們也嘗試使用多種方式，在我們的開發環境來復現這個問題：

• in dev configuration in VS

• on Windows with a production build

• on Ubuntu with a production build

• in Docker, using the actual production image

但是上述環境下，他們都沒有超過500mb的內存使用情況，都是增長到100-150mb左右就停止了。

期間，為了減輕容器因為超過限制的最大內存而頻繁重啟我們將內存限制從500mb增加到1000mb，在此之后，有趣的是內存的使用情況變得如下圖所示：

測試下來發現內存的使用并不是無限制的增大的，但是也是封頂600mb左右，并且這個數字在不同的容器實例以及實例重啟之后近乎保持一致。

這個現象清楚的表明我們的容器中的應用并沒有內存泄漏，只是有一塊內存被分配了而沒有得到釋放。所以我開始把關注點轉移到“運行在Kubernetes的.net程序是如何限制內存的“。

事實上Kubernetes最終也是將程序運行在docker容器中的，并且docker容器可以通過docker run --memory參數來限制內存的使用。所以我懷疑也許是Kubernetes并沒有傳遞任何有關內存限制的參數到docker容器實例中，所以.net程序理所當然的認為當前機器有好多好多的可用內存可以使用。

但是并不是這種情況，我們發現相反的內容（因為作者懷疑是Kubernetes沒有傳遞和內存相關的參數）在the documentation.

The?spec.containers[].resources.limits.memory?is converted to an integer, and used as the value of the?--memory?flag in the docker run command.

（這句話的意思是Kubernetes的spec.containers[].resources.limits.memory會自動沿用docker run中的--memory參數所設置的整數值）

這似乎又到了另一個死胡同了。我也嘗試在自己電腦里的docker中運行api程序，并且通過--memory參數傳遞多種內存限定值，但是1.我不能復現上述600mb內存使用的場景，內存只保持在150mb左右，2.也沒有觀察到容器實例運行的超過它的內存限制，即使我通過--memory參數來指定一個小于150mb的值，這個容器實例依然能夠在這個更小的內存限定值下運行的完好。

?

很早的時候我也在github上提過一個關于內存泄漏的issue關聯到Kestrel（core的一個基于libuv的新的服務器），并且在這一點上，Tim Seaward發了一個有趣的suggestion關于檢查我的應用在不同環境下所打印出的cpu的個數，因為cpu的是影響內存使用的一個巨大因素。

我嘗試在代碼里通過Environment.ProcessorCount在不同的環境下打印出的數量如下：

• On my machine, just doing dotnet run, the value was?4.

• On my machine, with Docker, it was?1.

• On Google Cloud Kubernetes it was?8.

這就能最終給我一個解釋了，因為cpu的數量真的會影響內存的使用數量。cpu核數越多，內存使用量也就越多（對于作者來說，他還不是確切的了解gc的類型，cpu的核數，與.net程序所使用內存的大小之間的關系，雖然this post這個鏈接包含了有關GC的資料）。

最終的建議呢，就是把GC模式從Server GC(服務器模式)切換到Workstation GC(模式)，這樣就能達到低內存使用率的優化效果。只需要在csproj項目文件中做如下動作：

<PropertyGroup> <ServerGarbageCollection>false</ServerGarbageCollection></PropertyGroup>

做了這個改動后，重新發布我的api，結果就如鄉下所示（藍色的線）：

workstation gc模式使得應用對于內存的使用變得更加”保守“，并且內存的使用從大約600mb降低到了100到150mb之間。假設工作站模式是通過犧牲一些性能和吞吐量來實現這個”600mb到150mb的效果“話（據官當服務器模式在某些場景下是相對優于工作站模式的），但是迄今為止我并沒有發現任何api速度和吞吐量的衰減，雖然我的這個api并不是一個對性能有著及其苛刻的要求。

?

通過這個故事總結到：OS，可用內存，cpu核數都是定位內存問題的關鍵因素，因為他們會大量影響想著.net的GC。如果你被問題卡住了，請不要猶豫的把問題拋出來，并且在很多.net 社區里面有很多極好的人會很樂于助人。

?=============================================分割線========================================

小弟我們公司下的項目也是這個問題，當時困擾了好久，為什么呢，因為之前在windows下面，內存占用不會”太明顯“，因為GC起到了決定性的作用，但是在core的環境下，在加之docker+linux，遇到這樣的時當時一度懷疑是docker的問題，當時也沒有像這位國外友人這樣去分析這個問題。通過這個問題我學到了如下：

1.學到了這位老哥定位思考問題的步驟，從是否是k8s的問題-》多環境問題-》github issue-》自己動手去類比推測-》最終解決問題。

2.GC的知識點補充：this post

3.除此之外還有很多知識點都隱藏到了：suggestion（希望大家仔細再看看）

4.我沒記錯的之前英文的官檔里，講項目配置文件的一節中提到了GC的配置

一開始（對GC的2種類型還不了解的情況），正常人看到這個true指的是激活該應用程序的GC垃圾回收，而并沒有注意到老外所調查的結果（true其實是指的激活服務器GC模式，false不是指不GC，而是指的使用工作站GC模式），我能說微軟是否能夠稍微“貼心點”指出true和false的真正區別（其實是我們自己.net研究的還不夠透徹，哈哈哈），這樣就不會有像我，像這個老外一樣，對于跑在docker容器里的core應用內存占用率過高而表示“質疑”。

ps：我們生產已改成false，當然true也沒問題，只不過服務器內存被“只吃不拉”而已。

原文地址：http://www.cnblogs.com/eastpig/p/7822892.html

---

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的Asp.net core应用在 Kubernetes上内存使用率过高问题分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。