1
cheng6563 349 天前
我这是 pod 的内存限制设置的很大,只为容错用。Java 服务由-Xmx 控制内存使用。dump 你设置那几个 VM 选项就行了,记得给存放 dump 的卷设置容量限制。。。
|
2
Ayanokouji OP @cheng6563 不考虑 dump 之后的参数。limit 设置的足够大,会不会造成资源浪费
|
3
edwinyzhang 349 天前
@Ayanokouji 不会, request 设置太大会资源浪费。
|
4
cdlnls 349 天前 1
感觉这个问题无解,要么牺牲掉一部份内存,要么放弃 dump 。
如果限制容器使用 2G 内存,这个时候设置 MaxRAMPercentage=25.0 ,那么 JVM 它就只使用 0.5G ,浪费了 1.5G 。 我感觉 oom dump 这个操作,是不适合放在容器里面执行的,一个原因是,dump 没控制好的情况下,会占用非常多的 CPU 资源,磁盘读写的压力也比较大。另外 dump 的时候也没办法处理请求,但是容器还是会接收请求,再加上重复的触发 dump ,就会有中断。而且有时候还没 dump 完,容器就因为健康检查被结束了,dump 了个寂寞。 所以我选择 java 在容器中时,不要 dump 。发现有内存泄漏的时候,再单独跑实例去复现问题,再执行 dump 。 还有个就是尽可能的测算出程序保证正常性能的情况下,到底需要多少内存,根据这个来指定值,应该是比较合理的方式。 |
5
Ayanokouji OP @cdlnls 这个问题确实无解,只能寻求个所谓的最佳实践,还有可能应用会操作 direct memory 。但是 dump 还是得要的,看起来只能牺牲一些内存了,MaxRAMPercentage=25.0 是默认值,一般会设置 MaxRAMPercentage=70.0 左右。
|
6
TaiShang 349 天前
可以看看 jemalloc,会有些优化的
|
7
anubu 349 天前 1
这两天刚好在调 MaxRAMPercentage 这个参数,在 JVM 没有 OOM 时 Pods 频繁 OOMKilled ,一般都是 MaxRAMPercentage 配置过高,需要根据自己的场景简单压测一下,目前配置在 65 左右比较合适。
limit 还是要限制一下,配置太大就没意义了,不好计算集群内存超配情况,也增加了不稳定性。超配太多争用的概率就高,驱逐就容易发生。驱逐还有滞后性,很多时候驱逐还没开始,因为节点内存不足,负载就拉上天了,然后就节点瘫了。 |
8
paranoiagu 349 天前 via Android
这边有 war 包的应用,发现非 jvm 需要 3-4G ,搞得 MaxRAMPercentage 设置 66.6 的话,pod 最大内存要 12G 才不会被杀。真不知道为什么要这么大内存
|
9
ysicing 349 天前
之前写过一个脚本,根据资源自动计算 jvm 相关值。这个是从 heroku 那里学到的。
|
10
cloud107202 348 天前
@paranoiagu 可能是容器的 jdk 版本不认容器平台 CRI 的 cgroupV2. 要检查并升级 jdk 到支持 cgroupV2 的小版本
|