容器內(nèi)的 Java 應(yīng)用可能會發(fā)生兩種類型的 OOM 異常，

• JVM 的 OOM：JVM 的堆棧元空間等內(nèi)存泄漏，導(dǎo)致沒有足夠的內(nèi)存來為對象分配空間并且GC也沒有空間可回收時，這時JVM會主動拋出錯誤并退出進(jìn)程，并留下相應(yīng)的錯誤記錄。容器退出狀態(tài)為exit code 137 reason: error（137表示容器收到SIGKILL信號而失敗，通常是達(dá)到資源限制或探針失敗）
• 容器 OOM：一般是JVM參數(shù)設(shè)置不合理，導(dǎo)致container_memory_working_set_bytes達(dá)到了cgroups限制，會在k8s事件中記錄且容器退出狀態(tài)為exit code 137 reason: OOM Killed

從容器來看

container_memory_working_set_bytes代表容器真實(shí)使用的內(nèi)存量，也是判斷超過limit的限制，超過limit則會導(dǎo)致oom；

container_memory_working_set_bytes = container_memory_usage_bytes - total_inactive_file（不活躍緩沖頁）；

container_memory_usage_bytes = container_memory_rss(進(jìn)程實(shí)際使用的物理內(nèi)存)+container_memory_cache（頁面緩存）+kernel memory；

container_memory_cache = total_active_file + inactive_file；

從jvm來看

進(jìn)程實(shí)際使用的物理內(nèi)存container_memory_rss = JVM內(nèi)存（堆棧元空間）+直接內(nèi)存+其他（文件描述符、GC消耗等等）；

容器真實(shí)使用的內(nèi)存量container_memory_working_set_bytes = JVM內(nèi)存（堆棧元空間）+直接內(nèi)存+其他（文件描述符、GC消耗等等）+container_memory_cache（頁面緩存）+kernel memory；

而預(yù)留內(nèi)存又=直接內(nèi)存+其他（文件描述符、GC消耗等等）+container_memory_cache（頁面緩存）+kernel memory；

綜上，容器真實(shí)使用的內(nèi)存為 JVM內(nèi)存（堆棧元空間）+ 預(yù)留內(nèi)存（直接內(nèi)存+文件描述符、GC消耗等 + 活躍的緩存頁 + kernel memory）

一種解決 JVM 內(nèi)存超限的方法

可以讓 JVM 自動感知 docker 容器的 cgroup 限制，從而動態(tài)的調(diào)整堆內(nèi)存大小。JDK8u131 在 JDK9 中有一個很好的特性，即 JVM 能夠檢測在 Docker 容器中運(yùn)行時有多少內(nèi)存可用。

為了使 jvm 保留根據(jù)容器規(guī)范的內(nèi)存，必須設(shè)置標(biāo)志 -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap。

注意：

如果將這兩個標(biāo)志與 Xms 和 Xmx 標(biāo)志一起設(shè)置，那么 jvm 的行為將是什么？

-Xmx 標(biāo)志將覆蓋-XX:+ UseCGroupMemoryLimitForHeap 標(biāo)志。

MaxDirectMemorySize

-XX:MaxDirectMemorySize=size用于設(shè)置New I/O(java.nio) direct-buffer allocations的峰值，-XX:MaxDirectMemorySize 沒顯式配置的時候，NIO direct memory 可申請的空間的上限就是 -Xmx 減去一個 survivor space 的預(yù)留大小。

如果不配置 -XX:MaxDirectMemorySize 并配置 -Xmx5G，則 默認(rèn) MaxDirectMemorySize 也將是 5G-survivor space 區(qū)，并且應(yīng)用程序的總堆+直接內(nèi)存使用量可能會增長到 5G + 5G = 10 G。

總結(jié)

以上為個人經(jīng)驗(yàn)，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論