建站
咨詢
售后
建站咨詢
新聞中心
背景
前段時間業(yè)務研發(fā)反饋說是他的應用內(nèi)存使用率很高，導致頻繁的重啟，讓我排查下是怎么回事；
在這之前我也沒怎么在意過這個問題，正好這次排查分析的過程做一個記錄。
首先我查看了監(jiān)控面板里的 Pod 監(jiān)控：
發(fā)現(xiàn)確實是快滿了，而此時去查看應用的 JVM 占用情況卻只有30%左右；說明并不是應用內(nèi)存滿了導致 JVM 的 OOM，而是 Pod 的內(nèi)存滿了，導致 Pod 的內(nèi)存溢出，從而被 k8s 殺掉了。
而 k8s 為了維持應用的副本數(shù)量就得重啟一個 Pod，所以看起來就是應用運行一段時間后就被重啟。
而這個應用配置的是 JVM 8G，容器申請的內(nèi)存是16G，所以 Pod 的內(nèi)存占用看起來也就 50% 左右。
容器的原理
在解決這個問題之前還是先簡單了解下容器的運行原理，因為在 k8s 中所有的應用都是運行在容器中的，而容器本質(zhì)上也是運行在宿主機上的一個個經(jīng)常而已。
但我們使用 Docker 的時候會感覺每個容器啟動的應用之間互不干擾，從文件系統(tǒng)、網(wǎng)絡、CPU、內(nèi)存這些都能完全隔離開來，就像兩個運行在不同的服務器中的應用。
其實這一點也不是啥黑科技，Linux 早就支持 2.6.x 的版本就已經(jīng)支持 namespace 隔離了，使用 namespace 可以將兩個進程完全隔離。
僅僅將資源隔離還不夠，還需要限制對資源的使用，比如 CPU、內(nèi)存、磁盤、帶寬這些也得做限制；這點也可以使用 cgroups 進行配置。
它可以限制某個進程的資源，比如宿主機是 4 核 CPU，8G 內(nèi)存，為了保護其他容器，必須給這個容器配置使用上限：1核 CPU，2G內(nèi)存。
這張圖就很清晰的表示了 namespace 和 cgroups 在容器技術(shù)中的作用，簡單來說就是：
- 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 內(nèi)存溢出導致容器退出會出現(xiàn) exit code 137 的一個 event 日志。
因為該應用的 JVM 內(nèi)存配置和容器的配置大小是一樣的，都是8GB，但 Java 應用還有一些非 JVM 管理的內(nèi)存，比如堆外內(nèi)存之類的，這樣很容易就導致容器內(nèi)存大小超過了限制的 8G 了，也就導致了容器內(nèi)存溢出。
云原生背景的優(yōu)化
因為這個應用本身使用的內(nèi)存不多，所以建議將堆內(nèi)存限制到 4GB，這樣就避免了容器內(nèi)存超限，從而解決了問題。
當然之后我們也會在應用配置欄里加上建議：推薦 JVM 的配置小于容器限制的 2/3，預留一些內(nèi)存。
其實本質(zhì)上還是開發(fā)模式?jīng)]有轉(zhuǎn)變過來，以傳統(tǒng)的 Java 應用開發(fā)模式甚至都不會去了解容器的內(nèi)存大小，因為以前大家的應用都是部署在一個內(nèi)存較大的虛擬機上，所以感知不到容器內(nèi)存的限制。
從而誤以為將兩者畫了等號，這一點可能在 Java 應用中尤為明顯，畢竟多了一個 JVM；甚至在老版本的 JDK 中如果沒有設置堆內(nèi)存大小，無法感知到容器的內(nèi)存限制，從而自動生成的 Xmx 大于了容器的內(nèi)存大小，以致于 OOM。
網(wǎng)頁題目：創(chuàng)新互聯(lián)背景下如何配置 JVM 內(nèi)存
當前路徑：http://m.5511xx.com/article/copjccd.html
