k8s容器 pod OOM, exit code:137

最新推荐文章于 2025-10-31 17:24:40 发布

原创最新推荐文章于 2025-10-31 17:24:40 发布 · 1.3w 阅读

12 ·

CC 4.0 BY-SA版权

文章标签：

#java #容器

作者在查看线上服务时，发现服务平均每天重启一次，提示OOM。添加OOM自动dump日志参数后未找到dump文件，经查找得知容器OOM和服务OOM不同。推测是jvm内存设置不合理，调小jvm堆内存设置后问题解决。还提到Java 8u191+及Java 10对容器内存限制的感知情况。

                    
                    某天查看线上服务，发现有个服务平均每天重启一次，通过k8s descripe pod podName 命令发现exit code： 137 reason: OOM Killed.
提示比较明显OOM（当时查了失败的容器内服务日志，发现没有异常信息，有点疑惑的）,然后果断在jvm配置里添加OOM自动dump日志参数，-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof，等着问题后分析日志原因（我们体量不大，同时又是多节点，所以直接线上搞了。一般情况下还是线上能优化就先优化下，测试环境验证，确定问题，并解决后再处理线上）
第二天发现pod又重启后，进入pod所在服务器，找到对应已关闭的docker容器，执行docker cp 命令，去copy dump文件发现路径不存在，没有该文件，有点蒙，感觉哪里又弄错了，于是重新检查配置是否生效，同时又去网上用exit code 137 OOM重新查找。
看了篇文章，意识到容器OOM和服务OOM不是一回事，容器OOM是因为容器占用内存超过了配置里内存的limit设置，导致容器服务把容器kill掉了，对与服务而言这时还是正常的，自然不会dump 日志了。理解了这层含义后，大致猜测jvm内存设置不合理，运行期间堆内存逐渐增大，jvm最大内存还没到，但是已经达到了容器内存的最大限制，然后容器被kill掉了。
于是调小了jvm堆内存设置，后续跟踪几天发现没在出现该情况。

PS：容器内jvm感知不到容器限制，Java 8u191 +支持加参数感知容器内存限制，以及设定内存占用比例，java10以后好像可以不加参数自动感知容器内存