linux容器內(nèi)存占用居高不下怎么解決

疑問

在出現(xiàn)系統(tǒng)內(nèi)存過高的情況下，我們可以通過 free -m 來查看當(dāng)前系統(tǒng)的內(nèi)存使用情況：

    

在發(fā)現(xiàn)是系統(tǒng)內(nèi)存占用高后，就有讀者提到，為什么不 “手動清理 Cache”，因為 Cache 高的話，可以通過 drop_caches 的方式來清理：

1. 清理 page cache：

$ echo 1 > /proc/sys/vm/drop_caches

2. 清理 dentries 和 inodes：

$ echo 2 > /proc/sys/vm/drop_caches

3. 清理 page cache、dentries 和 inodes：

$ echo 3 > /proc/sys/vm/drop_caches

但新問題又出現(xiàn)了，因為我們的命題是在容器中，在 Kubernetes 中，若執(zhí)行 drop_caches 相關(guān)命令，將會對 Node 節(jié)點上的所有其他應(yīng)用程序產(chǎn)生影響，尤其是那些占用大量 IO 并由于緩沖區(qū)高速緩存而獲得更好性能的應(yīng)用程序，可能會產(chǎn)生 “負(fù)面” 后果。 

表象

回歸原始，那就是為什么要排查這個問題，本質(zhì)原因就是容器設(shè)置了 Memory Limits，而容器在運(yùn)行中達(dá)到了 Limits 上限，被 OOM 掉了，所以我們想知道為什么會出現(xiàn)這個情況。

在前文中我們針對了五大類情況進(jìn)行了猜想：

• 頻繁申請重復(fù)對象。
• 不知名內(nèi)存泄露。
• madvise 策略變更。
• 監(jiān)控/判別條件有問題。
• 容器環(huán)境的機(jī)制。

在逐一排除后，后續(xù)發(fā)現(xiàn)容器的 Memory OOM 判定標(biāo)準(zhǔn)是 container_memory_working_set_bytes 指標(biāo)，其實際組成為 RSS + Cache（最近訪問的內(nèi)存、臟內(nèi)存和內(nèi)核內(nèi)存）。

在排除進(jìn)程內(nèi)存泄露的情況下，我們肯定是希望知道 Cache 中有什么，為什么占用了那么大的空間，此時我們可以通過 Linux pmap 來查看該容器進(jìn)程的內(nèi)存映射情況：

    

在上圖中，我們發(fā)現(xiàn)了大量的 mapping 為 anon 的內(nèi)存映射，最終 totals 確實達(dá)到了容器 Memory 相當(dāng)?shù)牧?，那?anon 又是什么呢。實質(zhì)上 anon 行表示在磁盤上沒有對應(yīng)的文件，也就是沒有實際存在的載體，是 anonymous。 

思考

既然存在如此多的 anon，結(jié)合先前的考慮，我們知道出現(xiàn)這種情況的服務(wù)都是文件處理型服務(wù)，包含大量的批量生成圖片、生成 PDF 等資源消耗型的任務(wù)，也就是會瞬間申請大量的內(nèi)存，使得系統(tǒng)的空閑內(nèi)存觸及全局最低水位線（global wmark_min），而在觸及全局最低水位線后，會嘗試進(jìn)行回收，實在不行才會觸發(fā) cgroup OOM 的行為。

那么更進(jìn)一步思考的是兩個問題，一個是 cgroup 達(dá)到 Limits 前的嘗試釋放仍然不足以支撐所需申請的連續(xù)內(nèi)存段，而另外一個問題就是為什么 Cache 并沒有釋放：

    

通過上圖，可以肯定該服務(wù)在凌晨 00：00-06：00 是沒有什么流量的，但是 container_memory_working_set_bytes 指標(biāo)依舊穩(wěn)定不變，排除 RSS 的原因，那配合指標(biāo)的查看基本確定是該 cgroup 的 Cache 沒有釋放。

而 Cache 的占用高，主要考慮是由于其頻繁操作文件導(dǎo)致，因為在 Linux 中，在第一次讀取文件時會將一份放到系統(tǒng) Cache，另外一份則放入進(jìn)程內(nèi)存中使用。關(guān)鍵點在于當(dāng)進(jìn)程運(yùn)行完畢關(guān)閉后，系統(tǒng) Cache 是不會馬上回收的，需要經(jīng)過系統(tǒng)的內(nèi)存管理后再適時釋放。

但我們發(fā)現(xiàn) Cache 的持續(xù)不釋放，進(jìn)程也沒外部流量，RSS 也低的可憐，Cache 不像被進(jìn)程占用住了的樣子（這一步的排除很重要），最終就考慮到是否 Linux 內(nèi)核在這塊內(nèi)存管理上存在 BUG 呢？ 

根因

問題版本

該服務(wù)所使用的 Kubernetes 是 1.11.5 版本，Linux 內(nèi)核版本為 3.10.x，時間為 2017 年 9 月：

$ uname -aLinux xxxxx-xxx-99bd5776f-k9t8z 3.10.0-693.2.2.el7.x86_64 #1 SMP Tue Sep 12 22:26:13 UTC 2017 x86_64 Linux

都算是有一定年代的老版本了。 

原因分析

memcg 是 Linux 內(nèi)核中管理 cgroup 內(nèi)存的模塊，但實際上在 Linux 3.10.x 的低內(nèi)核版本中存在不少實現(xiàn)上的 BUG，其中最具代表性的是 memory cgroup 中 kmem accounting 相關(guān)的問題（在低版本中屬于 alpha 特性）：

• slab 泄露：具體可詳見該文章 SLUB: Unable to allocate memory on node -1 中的介紹和說明。

• memory cgroup 泄露：在刪除容器后沒有回收完全，而 Linux 內(nèi)核對 memory cgroup 的總數(shù)限制是 65535 個，若頻繁創(chuàng)建刪除開啟了 kmem 的 cgroup，就會導(dǎo)致無法再創(chuàng)建新的 memory cgroup。

當(dāng)然，為什么出現(xiàn)問題后絕大多數(shù)是由 Kubernetes、Docker 的相關(guān)使用者發(fā)現(xiàn)的呢（從 issues 時間上來看），這與云原生的興起，這類問題與內(nèi)部容器化的機(jī)制相互影響，最終開發(fā)者 “發(fā)現(xiàn)” 了這類應(yīng)用頻繁出現(xiàn) OOM，于是開始進(jìn)行排查。 

解決方案 

調(diào)整內(nèi)核參數(shù)

關(guān)閉 kmem accounting：

cgroup.memory=nokmem

也可以通過 kubelet 的 nokmem Build Tags 來編譯解決：

$ kubelet GOFLAGS="-tags=nokmem"

但需要注意，kubelet 版本需要在 v1.14 及以上。

升級內(nèi)核版本

升級 Linux 內(nèi)核至 kernel-3.10.0-1075.el7 及以上就可以修復(fù)這個問題，詳細(xì)可見 slab leak causing a crash when using kmem control group，其在發(fā)行版中 CentOS 7.8 已經(jīng)發(fā)布。