标签归档：K8S

JVM 堆外内存泄漏分析（一）

发表于由
回复

1. JVM 感知容器资源

Java 应用部署在 Kubernetes 集群里，每个容器只运行一个进程， JVM 的启动命令是打包在镜像文件里的。

常规的方式是采用 -Xmx4g -Xms2g 这样的参数来指定 JVM 堆的最大、最小尺寸，如果需要调整堆大小就需要重新打包镜像。

为了避免因为修改堆大小而重新打包，从 JDK 8u191 版本开始支持 JVM 感知容器资源限制，这样在调整 JVM 内存分配时就不需要重新打包镜像文件，采用下面的参数来使 JVM 在启动时感知到容器的资源限制，并设定堆的大小：

-XX:+UseCGroupMemoryLimitForHeap
-XX:InitialRAMPercentage=60.00
-XX:MaxRAMPercentage=80.00
-XX:MinRAMPercentage=60.00

假如分配给容器的内存上限是 4G，那么上述配置，JVM 堆的初始大小和最小尺寸是 4G * 0.6 即 2.4G，最大尺寸是 4G * 0.8 即 3.2G。

2. JVM 被 oomkill

上面的配置运行一段时间后发现容器自动重启了，在 linux 下通过 dmesg 命令查看系统日志，可以看到类似下面的日志：

Aug  8 15:32:40 H-LDOCKER-01 kernel: [ pid ]   uid   tgid   total_vm      rss        nr_ptes   nr_pmds   swapents   oom_score_adj  name
Aug  8 15:32:40 H-LDOCKER-01 kernel: [33775]   1001  33775  7624373       2036828    4476      32        0          -998           java
Aug  8 15:32:40 H-LDOCKER-01 kernel: Memory cgroup out of memory: Kill process 33775 (java) score 0 or sacrifice child
Aug  8 15:32:40 H-LDOCKER-01 kernel: Killed process 33775 (java) total-vm:30497492kB, anon-rss:8134056kB, file-rss:13256kB

继续阅读 →

容器下 -XX:+HeapDumpOnOutOfMemoryError 未生成 dump 文件的问题

发表于由
回复

JVM 的启动命令一般都会加上参数 -XX:+HeapDumpOnOutOfMemoryError=/path/to/save/dump.hprof，用于在 JVM 发生 OOM 时自动生成内存 dump 文件。

应用在生产环境是运行在 Docker 容器里、由 K8S 负责管理容器。

但是有的应用发生 OOM 时，在 /path/to/save/dump.hprof 路径下并没有生成对应的 dump 文件。

优秀的运维同事小伍在测试环境进行了各种测试，得出以下两种情况没法生产文件：
1. /path/to/save/ 如果中间层的目录没有提前建好，是没法生成 dump 文件的。
2. 堆外内存不足 800M 时，也没法生成 dump 文件。

第1点没啥问题，文件所在的目录没有提前建好是会报 java.io.FileNotFoundException 异常的。

第2点其实是因为 JVM 运行在容器里，容器允许使用的内存是有上限的，比如分配给容器的是 4G 内存，JVM 堆占用 80%，那么堆外内存就只能占用 20% 即 800M。

发生 OOM 时，JVM 占用了 3.2G；对于堆外内存，线程、JVM自身、应用申请的本地内存等都要在这里分配，OOM dump 也需要利用堆外内存，容器使用的总内存达到 4G 内存上限时，触发系统的 oomkiller 机制把容器进程杀死。

这带来一个小问题：如果要保证 JVM OOM 自动 dump 机制能顺利执行，我们就需要在容器里预留出足够的堆外内存，每个容器都得考虑预留，这就带来内存利用率的问题了。如果 JVM 直接运行在宿主操作系统，没有容器的限制，能申请的堆外内存是受限于系统能分配的内存的，不同应用的 JVM 可共享这个可分配内存空间。

欢迎关注我的微信公众号: coderbee笔记，可以更及时回复你的讨论。