背景

前段時(shí)間業(yè)務(wù)研發(fā)反饋說(shuō)是他的應(yīng)用內(nèi)存使用率很高，導(dǎo)致頻繁的重啟，讓我排查下是怎么回事；

在這之前我也沒(méi)怎么在意過(guò)這個(gè)問(wèn)題，正好這次排查分析的過(guò)程做一個(gè)記錄。

首先我查看了監(jiān)控面板里的 Pod 監(jiān)控：

發(fā)現(xiàn)確實(shí)是快滿了，而此時(shí)去查看應(yīng)用的 JVM 占用情況卻只有30%左右；說(shuō)明并不是應(yīng)用內(nèi)存滿了導(dǎo)致 JVM 的 OOM，而是 Pod 的內(nèi)存滿了，導(dǎo)致 Pod 的內(nèi)存溢出，從而被 k8s 殺掉了。

而 k8s 為了維持應(yīng)用的副本數(shù)量就得重啟一個(gè) Pod，所以看起來(lái)就是應(yīng)用運(yùn)行一段時(shí)間后就被重啟。

而這個(gè)應(yīng)用配置的是 JVM 8G，容器申請(qǐng)的內(nèi)存是16G，所以 Pod 的內(nèi)存占用看起來(lái)也就 50% 左右。

容器的原理

在解決這個(gè)問(wèn)題之前還是先簡(jiǎn)單了解下容器的運(yùn)行原理，因?yàn)樵?k8s 中所有的應(yīng)用都是運(yùn)行在容器中的，而容器本質(zhì)上也是運(yùn)行在宿主機(jī)上的一個(gè)個(gè)經(jīng)常而已。

但我們使用 Docker 的時(shí)候會(huì)感覺(jué)每個(gè)容器啟動(dòng)的應(yīng)用之間互不干擾，從文件系統(tǒng)、網(wǎng)絡(luò)、CPU、內(nèi)存這些都能完全隔離開(kāi)來(lái)，就像兩個(gè)運(yùn)行在不同的服務(wù)器中的應(yīng)用。

其實(shí)這一點(diǎn)也不是啥黑科技，Linux 早就支持 2.6.x 的版本就已經(jīng)支持 namespace 隔離了，使用 namespace 可以將兩個(gè)進(jìn)程完全隔離。

僅僅將資源隔離還不夠，還需要限制對(duì)資源的使用，比如 CPU、內(nèi)存、磁盤、帶寬這些也得做限制；這點(diǎn)也可以使用 cgroups 進(jìn)行配置。

它可以限制某個(gè)進(jìn)程的資源，比如宿主機(jī)是 4 核 CPU，8G 內(nèi)存，為了保護(hù)其他容器，必須給這個(gè)容器配置使用上限：1核 CPU，2G內(nèi)存。

這張圖就很清晰的表示了 namespace  和 cgroups 在容器技術(shù)中的作用，簡(jiǎn)單來(lái)說(shuō)就是：

• namespace 負(fù)責(zé)隔離
• cgroups 負(fù)責(zé)限制

在 k8s 中也有對(duì)應(yīng)的提現(xiàn)：

resources:
    requests:
      memory: 1024Mi
      cpu: 0.1
    limits:
      memory: 1024Mi
      cpu: 4

這個(gè)資源清單表示該應(yīng)用至少需要為一個(gè)容器分配一個(gè) 0.1 核和 1024M 的資源，CPU 的最高上限為 4 個(gè)核心。

不同的OOM

回到本次的問(wèn)題，可以確認(rèn)是容器發(fā)生了 OOM 從而導(dǎo)致被 k8s 重啟，這也是我們配置 limits 的作用。

k8s 內(nèi)存溢出導(dǎo)致容器退出會(huì)出現(xiàn) exit code 137 的一個(gè) event 日志。

因?yàn)樵搼?yīng)用的 JVM 內(nèi)存配置和容器的配置大小是一樣的，都是8GB，但 Java 應(yīng)用還有一些非 JVM 管理的內(nèi)存，比如堆外內(nèi)存之類的，這樣很容易就導(dǎo)致容器內(nèi)存大小超過(guò)了限制的 8G 了，也就導(dǎo)致了容器內(nèi)存溢出。

云原生背景的優(yōu)化

因?yàn)檫@個(gè)應(yīng)用本身使用的內(nèi)存不多，所以建議將堆內(nèi)存限制到 4GB，這樣就避免了容器內(nèi)存超限，從而解決了問(wèn)題。

當(dāng)然之后我們也會(huì)在應(yīng)用配置欄里加上建議：推薦 JVM 的配置小于容器限制的 2/3，預(yù)留一些內(nèi)存。

其實(shí)本質(zhì)上還是開(kāi)發(fā)模式?jīng)]有轉(zhuǎn)變過(guò)來(lái)，以傳統(tǒng)的 Java 應(yīng)用開(kāi)發(fā)模式甚至都不會(huì)去了解容器的內(nèi)存大小，因?yàn)橐郧按蠹业膽?yīng)用都是部署在一個(gè)內(nèi)存較大的虛擬機(jī)上，所以感知不到容器內(nèi)存的限制。

從而誤以為將兩者畫(huà)了等號(hào)，這一點(diǎn)可能在 Java 應(yīng)用中尤為明顯，畢竟多了一個(gè) JVM；甚至在老版本的 JDK 中如果沒(méi)有設(shè)置堆內(nèi)存大小，無(wú)法感知到容器的內(nèi)存限制，從而自動(dòng)生成的 Xmx 大于了容器的內(nèi)存大小，以致于 OOM。