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

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐