Java 应用程序在 Kubernetes 如何配置内存，最大限度避免容器 OOMKilled

我这是 pod 的内存限制设置的很大，只为容错用。Java 服务由-Xmx 控制内存使用。dump 你设置那几个 VM 选项就行了，记得给存放 dump 的卷设置容量限制。。。

@cheng6563 不考虑 dump 之后的参数。limit 设置的足够大，会不会造成资源浪费

@Ayanokouji 不会, request 设置太大会资源浪费。

感觉这个问题无解，要么牺牲掉一部份内存，要么放弃 dump 。
如果限制容器使用 2G 内存，这个时候设置 MaxRAMPercentage=25.0 ，那么 JVM 它就只使用 0.5G ，浪费了 1.5G 。

我感觉 oom dump 这个操作，是不适合放在容器里面执行的，一个原因是，dump 没控制好的情况下，会占用非常多的 CPU 资源，磁盘读写的压力也比较大。另外 dump 的时候也没办法处理请求，但是容器还是会接收请求，再加上重复的触发 dump ，就会有中断。而且有时候还没 dump 完，容器就因为健康检查被结束了，dump 了个寂寞。

所以我选择 java 在容器中时，不要 dump 。发现有内存泄漏的时候，再单独跑实例去复现问题，再执行 dump 。

还有个就是尽可能的测算出程序保证正常性能的情况下，到底需要多少内存，根据这个来指定值，应该是比较合理的方式。

@cdlnls 这个问题确实无解，只能寻求个所谓的最佳实践，还有可能应用会操作 direct memory 。但是 dump 还是得要的，看起来只能牺牲一些内存了，MaxRAMPercentage=25.0 是默认值，一般会设置 MaxRAMPercentage=70.0 左右。

可以看看 jemalloc,会有些优化的

这两天刚好在调 MaxRAMPercentage 这个参数，在 JVM 没有 OOM 时 Pods 频繁 OOMKilled ，一般都是 MaxRAMPercentage 配置过高，需要根据自己的场景简单压测一下，目前配置在 65 左右比较合适。

limit 还是要限制一下，配置太大就没意义了，不好计算集群内存超配情况，也增加了不稳定性。超配太多争用的概率就高，驱逐就容易发生。驱逐还有滞后性，很多时候驱逐还没开始，因为节点内存不足，负载就拉上天了，然后就节点瘫了。

这边有 war 包的应用，发现非 jvm 需要 3-4G ，搞得 MaxRAMPercentage 设置 66.6 的话，pod 最大内存要 12G 才不会被杀。真不知道为什么要这么大内存

之前写过一个脚本，根据资源自动计算 jvm 相关值。这个是从 heroku 那里学到的。

@paranoiagu 可能是容器的 jdk 版本不认容器平台 CRI 的 cgroupV2. 要检查并升级 jdk 到支持 cgroupV2 的小版本