总结：记一次K8S容器OOM案例

小魏的博客

已于 2022-07-20 14:27:28 修改

阅读量4.5k

点赞数 2

分类专栏： Java 文章标签： jvm java linux

于 2022-07-15 18:28:30 首次发布

本文链接：https://blog.csdn.net/w2009211777/article/details/125810250

版权

Java 专栏收录该内容

88 篇文章 6 订阅

订阅专栏

一、背景

最近遇到个现象，hubble-api-open组件过段时间会内容占满，从而被K8S强制重启。

让我困惑的是，已经设置了-XX:MaxRAMPercentage=75.0，我觉得留有了一定的空间，不应该会占满，所以想深究下原因。

-XX:MaxRAMPercentage是设置JVM的最大堆内存占虚机或pod（limits）的比例，默认为25.0。我设置的是75.0。

注意呦：是堆内存哦！不包含元空间，非堆这些，所以Java进程实际使用的内存可能是超过配置的limits的75%。

二、是否是配置没有起作用？如何验证？

要验证的话，其实也简单，看下JVM配置的最大堆内存是多少即可。

好在我们已经接入了prometheus，接入了Actuator，因此我们是可以看到配置的最大内存的指标的，检查如下：

jvm_memory_max_bytes{area="nonheap",id="Code Cache",} 2.5165824E8
jvm_memory_max_bytes{area="nonheap",id="Metaspace",} -1.0
jvm_memory_max_bytes{area="nonheap",id="Compressed Class Space",} 1.073741824E9
jvm_memory_max_bytes{area="heap",id="G1 Eden Space",} -1.0
jvm_memory_max_bytes{area="heap",id="G1 Survivor Space",} -1.0
jvm_memory_max_bytes{area="heap",id="G1 Old Gen",} 4.718592E9

上面的area="heap"的三个加起来就是配置的最大的堆内存，算一下：

4.718592E9 = 4.718592 乘以 10的9次方 = 4.718592 * 10^9 = 4718592000 byte = 4718592000 byte = 4608000 KB = 4500 MB = 4.395GB

也就是配置的JVM允许使用的最大的堆内存是4.395GB，是不是75%呢？我们需要去看下limits的配置：可见是5.86GB

5.86*0.75 = 4.395GB，和我们从指标上看到的是一致的，说明配置生效了

三、为什么会OOM？

1、是否是非堆内存导致的？

答案：不是

grafana看下当前RSS和WSS，可以看到已经快100%了：

但是我们看JVM进程实际使用的，其实并不高：

jvm_memory_used_bytes：表示JVM实际已经使用的内存

jvm_memory_committed_bytes：可供Java虚拟机使用的已提交的内存量

committed是当前可使用的内存大小（包括已使用的），committed >= used。committed不足时jvm向系统申请

jvm_memory_max_bytes：表示最大可以申请的内存量

committed <= max

再看下其它相关内存（这个内存也是动态变化的）：

jvm_memory_committed_bytes：可供Java虚拟机使用的已提交的内存量

这理论上是从操作系统层面看到的Java进程占用的内存。

如下堆和非堆总计也就4.2GB左右（所以不是非堆导致），并没有达到Limits的97.49%

进入容器，用top命令查看，占了5.83g内存，明显还是要大于jvm_memory_committed_bytes，所以，java应该还有使用的没有通过指标列出来，这块需要找下

下面是不同内存区域最大可申请的内存量

jvm_memory_max_bytes：表示最大可以申请的内存量

本来我觉得JVM在TOP中使用的内存大小是按照JVM实际使用量计算，即按照jvm_memory_used_bytes，但是经过排查，其实是jvm_memory_committed_bytes + JVM其它内存（这块待研究）

从TOP命令看（即从操作系统层面看），确实是Java进程占用了所有的内存，所以java除了已提交的内存，一定还有其它的。

如果按照jvm_memory_committed_bytes来计算，那么差不多占了4.2GB左右，这个数值应该等于TOP中的RES，但是为什么差距那么大呢？

2、是不是因为线程占用的内存没有在prometheus指标中体现？

我觉得这个倒是有可能的，看了下线程相关的指标：

jvm_threads_live 906.0
tomcat_threads_current{name="http-nio-9507",} 200.0

可见JVM线程 + tomcat线程有差不多1000个了，假设每个1M的话，差不多占了1GB，所以这块严重怀疑。

这样算下来其实就差不多了，4.2GB + 1GB = 5.2GB

怎么验证呢？每个线程栈大小是多大呢？

通过dump命令拉取到某个时刻的线程数：879MB

而在jvm_memory_committed_bytes指标中并未看到类似大小的指标，所以我判断应该是没有在memory相关指标中有显示。

但是算上线程栈的话，假设5.2GB，和实际占用5.83还是差几百兆，因此应该还有一部分没有算上。

3、其它内存

待续……

四、JVM占用内存与操作系统层面看JVM占用内存

在JDK 8及之前，哪怕GC之后占用内存下降，得到的内存空间也仅仅是从Used转变为Committed，在JVM一侧看这些已经是空闲内存了，但在OS一侧看来，仍然是被JVM占用的状态。

从JDK 9起，加入了ShrinkHeapInSteps参数，或者说修复了以前的UseAggressiveHeapShrink参数的问题（https://bugs.openjdk.java.net/browse/JDK-8146436），让OS一侧能看到JVM主动释放的内存。

但这个行为必须是与具体收集器相关的，其他几款收集器的改进并不活跃，G1在这个时期有改动，让它在FullGC时顺带Decommit空闲内存回OS（https://bugs.openjdk.java.net/browse/JDK-8038423）。

不过，以上改进仍然是效果很差，因为G1是并发增量收集，FullGC是很罕见的，所以通常加了这个参数也不容易见到效果。

到了JDK 12，发布了JEP 346（https://openjdk.java.net/jeps/346），这个JEP的改进就是让G1能在正常的不产生FullGC的收集循环中，也能自动Decommit空闲内存回OS（通过G1PeriodicGCInterval参数），后来的Shenandoah收集器也共用了这部分代码。

到了JDK 13，ZGC默认就有Decommit行为，不需要额外参数了。

五、Java程序的占用内存构成

虚拟机内存与本地内存的区别
Java虚拟机在执行的时候会把管理的内存分配成不同的区域，这些区域被称为虚拟机内存，同时，对于虚拟机没有直接管理的物理内存，也有一定的利用，这些被利用却不在虚拟机内存数据区的内存，我们称它为本地内存，这两种内存有一定的区别：

JVM内存

受虚拟机内存大小的参数控制，当大小超过参数设置的大小时就会报OOM

本地内存

本地内存不受虚拟机内存参数的限制，只受物理内存容量的限制，虽然不受参数的限制，但是如果内存的占用超出物理内存的大小，同样也会报OOM

六、各个主要内存区域存放的数据

1、堆

java堆是JVM内存中最大的一块，由所有线程共享，是由垃圾收集器管理的内存区域。

2、虚拟机栈

虚拟机栈是线程私有的，随线程生灭。

由于一个线程默认分配1M空间，一个Java进程一般都有几百个线程，升至上千个线程，因此虚拟机栈一般是除了堆之外，最占用内存的区域。

另外，程序计数器是线程私有的，每个线程都已自己的程序计数器，所以，程序计数器的内容不用另外算，直接计算线程的内存即可。

3、元空间(Meta Space)

元空间类似于老版本的方法区。非堆区。

元空间一般占内存100MB左右，是堆，栈之外，最占用内存的区域。

元空间主要包含两部分数据：

类信息：或者说类的元信息。
- 类的元信息里面放置了类的基本信息，包括类的版本、字段、方法、接口以及常量池表
- 常量池表:存储了类在编译期间生成的字面量、符号引用
运行时常量池：主要存放在类加载后被解析的字面量与符号引用

方法区是所有线程共享的内存。

在java8以前是放在JVM内存中的，由永久代实现，受JVM内存大小参数的限制。

在java8中移除了永久代的内容，方法区由元空间(Meta Space)实现，并直接放到了本地内存中，不受JVM参数的限制(当然，如果物理内存被占满了，方法区也会报OOM)，并且将原来放在方法区的字符串常量池和静态变量都转移到了Java堆中。

CCS（Compressed Class Space）

在Java8以前，有一个选项是UseCompressedOops。所谓OOPS是指“ordinary object pointers“，就是原始指针。Java Runtime可以用这个指针直接访问指针对应的内存，做相应的操作（比如发起GC时做copy and sweep）。

那么Compressed是啥意思？64bit的JVM出现后，OOPS的尺寸也变成了64bit，比之前的大了一倍。这会引入性能损耗——占的内存double了，并且同尺寸的CPU Cache要少存一倍的OOPS。

于是就有了UseCompressedOops这个选项。打开后，OOPS变成了32bit。但32bit的base是8，所以能引用的空间是32GB——这远大于目前经常给jvm进程内存分配的空间。

Compressed Class Space 是 Metaspace 的一部分，默认值是 1G。所以其实 Compressed Class Space 这个名字取得很误导，压缩的并不是 Klass，而是 Klass*。

compressed class space 空间的大小，是通过 -XX:CompressedClassSpaceSize 指定的。

如下占用了13MB左右空间，比较小。非堆区。

jvm_memory_committed_bytes{application="hubble-biz-host",area="nonheap",id="Compressed Class Space",} 1.3549568E7

4、代码缓存区

代码缓存区是一块存储编译后代码的区域。非堆区。

如下大致占了80MB左右的空间

jvm_memory_committed_bytes{application="hubble-biz-host",area="nonheap",id="Code Cache",} 7.9757312E7

5、本地方法栈(Native Method Stacks)

本地方法栈与虚拟机栈的作用是相似的,都会抛出OutOfMemoryError和StackOverFlowError，都是线程私有的，主要的区别在于：

虚拟机栈执行的是java方法
本地方法栈执行的是native方法

直接内存

执行native方法会产生直接内存。

直接内存位于本地内存，不属于JVM内存，但是也会在物理内存耗尽的时候报OOM。非堆区。

直接内存（DirectMemory）的容量大小可通过-XX：MaxDirectMemorySize参数来指定，如果不去指定，则默认与Java堆最大值（由-Xmx指定）一致。

这块占用的内存经过观察一般不高，如下可知只有大约4MB，如下：

jvm_buffer_memory_used_bytes{application="hubble-biz-host",id="direct",} 4169692.0

在jdk1.4中加入了NIO(New Input/Putput)类，引入了一种基于通道(channel)与缓冲区(buffer)的新IO方式，它可以使用native函数直接分配堆外内存，然后通过存储在java堆中的DirectByteBuffer对象作为这块内存的引用进行操作，这样可以在一些场景下大大提高IO性能，避免了在java堆和native堆来回复制数据。