原文：https://blog.markvincze.com/troubleshooting-high-memory-usage-with-asp-net-core-on-kubernetes/ ps：我不是死板翻譯原文的，儘量的通俗一點，如有不對歡迎指出，謝謝哈。 在生產環境中，我們把asp.ne ...
原文：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也沒問題，只不過伺服器記憶體被“只吃不拉”而已。
最後希望大家多多支持core，為張大大打個廣告：微信公眾號搜索”opendotnet“進行關註，知識共分享。
