云原生背景下如何配置 JVM 內(nèi)存
前段時間業(yè)務(wù)研發(fā)反饋說是他的應(yīng)用內(nèi)存使用率很高，導(dǎo)致頻繁的重啟，讓我排查下是怎么回事；
在這之前我也沒怎么在意過這個問題，正好這次排查分析的過程做一個記錄。
首先我查看了監(jiān)控面板里的 Pod 監(jiān)控：
發(fā)現(xiàn)確實(shí)是快滿了，而此時去查看應(yīng)用的 JVM 占用情況卻只有30%左右；說明并不是應(yīng)用內(nèi)存滿了導(dǎo)致 JVM 的 OOM，而是 Pod 的內(nèi)存滿了，導(dǎo)致 Pod 的內(nèi)存溢出，從而被 k8s 殺掉了。
而 k8s 為了維持應(yīng)用的副本數(shù)量就得重啟一個 Pod，所以看起來就是應(yīng)用運(yùn)行一段時間后就被重啟。
在解決這個問題之前還是先簡單了解下容器的運(yùn)行原理，因?yàn)樵?k8s 中所有的應(yīng)用都是運(yùn)行在容器中的，而容器本質(zhì)上也是運(yùn)行在宿主機(jī)上的一個個經(jīng)常而已。
但我們使用 Docker 的時候會感覺每個容器啟動的應(yīng)用之間互不干擾，從文件系統(tǒng)、網(wǎng)絡(luò)、CPU、內(nèi)存這些都能完全隔離開來，就像兩個運(yùn)行在不同的服務(wù)器中的應(yīng)用。
其實(shí)這一點(diǎn)也不是啥黑科技，Linux 早就支持 2.6.x 的版本就已經(jīng)支持 namespace 隔離了，使用 namespace 可以將兩個進(jìn)程完全隔離。
僅僅將資源隔離還不夠，還需要限制對資源的使用，比如 CPU、內(nèi)存、磁盤、帶寬這些也得做限制；這點(diǎn)也可以使用 cgroups 進(jìn)行配置。
它可以限制某個進(jìn)程的資源，比如宿主機(jī)是 4 核 CPU，8G 內(nèi)存，為了保護(hù)其他容器，必須給這個容器配置使用上限：1核 CPU，2G內(nèi)存。
這張圖就很清晰的表示了 namespace ?和 cgroups 在容器技術(shù)中的作用，簡單來說就是：
- namespace 負(fù)責(zé)隔離
- cgroups 負(fù)責(zé)限制
在 k8s 中也有對應(yīng)的提現(xiàn)：
??resources:
????requests:
??????memory:?1024Mi
??????cpu:?0.1
????limits:
??????memory:?1024Mi
??????cpu:?4
這個資源清單表示該應(yīng)用至少需要為一個容器分配一個 0.1 核和 1024M 的資源，CPU 的最高上限為 4 個核心。
不同的OOM回到本次的問題，可以確認(rèn)是容器發(fā)生了 OOM 從而導(dǎo)致被 k8s 重啟，這也是我們配置 limits 的作用。
k8s 內(nèi)存溢出導(dǎo)致容器退出會出現(xiàn) exit code 137 的一個 event 日志。
因?yàn)樵搼?yīng)用的 JVM 內(nèi)存配置和容器的配置大小是一樣的，都是8GB，但 Java 應(yīng)用還有一些非 JVM 管理的內(nèi)存，比如堆外內(nèi)存之類的，這樣很容易就導(dǎo)致容器內(nèi)存大小超過了限制的 8G 了，也就導(dǎo)致了容器內(nèi)存溢出。
云原生背景的優(yōu)化因?yàn)檫@個應(yīng)用本身使用的內(nèi)存不多，所以建議將堆內(nèi)存限制到 4GB，這樣就避免了容器內(nèi)存超限，從而解決了問題。
當(dāng)然之后我們也會在應(yīng)用配置欄里加上建議：推薦 JVM 的配置小于容器限制的 2/3，預(yù)留一些內(nèi)存。
其實(shí)本質(zhì)上還是開發(fā)模式?jīng)]有轉(zhuǎn)變過來，以傳統(tǒng)的 Java 應(yīng)用開發(fā)模式甚至都不會去了解容器的內(nèi)存大小，因?yàn)橐郧按蠹业膽?yīng)用都是部署在一個內(nèi)存較大的虛擬機(jī)上，所以感知不到容器內(nèi)存的限制。
從而誤以為將兩者畫了等號，這一點(diǎn)可能在 Java 應(yīng)用中尤為明顯，畢竟多了一個 JVM；甚至在老版本的 JDK 中如果沒有設(shè)置堆內(nèi)存大小，無法感知到容器的內(nèi)存限制，從而自動生成的 Xmx 大于了容器的內(nèi)存大小，以致于 OOM。
從源碼徹底理解 Prometheus/VictoriaMetrics 中的 relabel/metric_configs 配置
通過 Pulsar 源碼徹底解決重復(fù)消費(fèi)問題
一個詭異的 Pulsar InterruptedException 異常
