k8s之容器內存與JVM內存解讀

更新時間：2025年07月04日 09:20:31 作者：傅里葉、

這篇文章主要介紹了k8s之容器內存與JVM內存,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教

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

從容器來看

container_memory_working_set_bytes代表容器真實使用的內存量，也是判斷超過limit的限制，超過limit則會導致oom；

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

container_memory_usage_bytes = container_memory_rss(進程實際使用的物理內存)+container_memory_cache（頁面緩存）+kernel memory；

container_memory_cache = total_active_file + inactive_file；

從jvm來看

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

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

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

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

一種解決 JVM 內存超限的方法

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

為了使 jvm 保留根據容器規(guī)范的內存，必須設置標志 -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap。

注意：

如果將這兩個標志與 Xms 和 Xmx 標志一起設置，那么 jvm 的行為將是什么？

-Xmx 標志將覆蓋-XX:+ UseCGroupMemoryLimitForHeap 標志。

MaxDirectMemorySize

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

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