背景

前段時間業(yè)務研發(fā)反饋說是他的應用內存使用率很高，導致頻繁的重啟，讓我排查下是怎么回事；

在這之前我也沒怎么在意過這個問題，正好這次排查分析的過程做一個記錄。

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

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

而 k8s 為了維持應用的副本數(shù)量就得重啟一個 Pod，所以看起來就是應用運行一段時間后就被重啟。

而這個應用配置的是 JVM 8G，容器申請的內存是16G，所以 Pod 的內存占用看起來也就 50% 左右。

容器的原理

在解決這個問題之前還是先簡單了解下容器的運行原理，因為在 k8s 中所有的應用都是運行在容器中的，而容器本質上也是運行在宿主機上的一個個經常而已。

但我們使用 Docker 的時候會感覺每個容器啟動的應用之間互不干擾，從文件系統(tǒng)、網絡、CPU、內存這些都能完全隔離開來，就像兩個運行在不同的服務器中的應用。

其實這一點也不是啥黑科技，Linux 早就支持 2.6.x 的版本就已經支持 namespace 隔離了，使用 namespace 可以將兩個進程完全隔離。

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

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

這張圖就很清晰的表示了 namespace  和 cgroups 在容器技術中的作用，簡單來說就是：

• namespace 負責隔離
• cgroups 負責限制

在 k8s 中也有對應的提現(xiàn)：

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

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

不同的OOM

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

k8s 內存溢出導致容器退出會出現(xiàn) exit code 137 的一個 event 日志。

因為該應用的 JVM 內存配置和容器的配置大小是一樣的，都是8GB，但 Java 應用還有一些非 JVM 管理的內存，比如堆外內存之類的，這樣很容易就導致容器內存大小超過了限制的 8G 了，也就導致了容器內存溢出。

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

因為這個應用本身使用的內存不多，所以建議將堆內存限制到 4GB，這樣就避免了容器內存超限，從而解決了問題。

當然之后我們也會在應用配置欄里加上建議：推薦 JVM 的配置小于容器限制的 2/3，預留一些內存。

其實本質上還是開發(fā)模式沒有轉變過來，以傳統(tǒng)的 Java 應用開發(fā)模式甚至都不會去了解容器的內存大小，因為以前大家的應用都是部署在一個內存較大的虛擬機上，所以感知不到容器內存的限制。

從而誤以為將兩者畫了等號，這一點可能在 Java 應用中尤為明顯，畢竟多了一個 JVM；甚至在老版本的 JDK 中如果沒有設置堆內存大小，無法感知到容器的內存限制，從而自動生成的 Xmx 大于了容器的內存大小，以致于 OOM。