乐趣区

关于java:记一次jvm堆外内存OOM的解决过程

本文记录一次堆外内存 OOM 的排查过程。
周末的时候共事对线上服务进行了一次扩容,本认为只是简略减少几个实例而已,后果新实例接入流量后疯狂报警,只能马上切换下线,查看日志后发现如下谬误:

jstat 命令查看 GC 信息发现 fullgc 十分多

因为线上服务部署在 k8s 集群中,实例是运行在 docker 环境的,镜像没有任何批改,而这个镜像曾经上线将近一个月了,为什么曾经上线的服务没有问题而新退出的实例疯狂报警,带着一头雾水回顾了下之前排查线上性能问题的各种伎俩,貌似都对堆外内存问题排查大刀阔斧,周末始终思考这个问题也进行了一些尝试,无果。
转瞬周一到了,到公司后第一工夫查看了相干的一些参数,看了曾经在线上的服务,吓了一跳,线上服务堆外内存也靠近爆满 (6G 下限),惟恐线上服务全副挂掉。
静下心来想了下咱们服务中哪些模块应用了堆外内存,第一个想到的是咱们的 RPC 框架,因为底层应用了 netty 会应用堆外内存,为了验证这个问题我也查看了另外一组十分相近的上游服务,后果发现这个服务的堆外内存使用量十分小,只有 20M 左右,排除掉 RPC 组件的问题。
为了看一下堆外内存的增长曲线,我将线上服务又扩了一个正本,后果发现一个重要的线索,实例启动胜利后堆外内存根本就曾经靠近下限了。那么就省去流量模仿了,于是我在本地启动了一个服务,查看内存应用状况,后果发现启动阶段堆外内存暴涨,到肯定水平后开始稳固,于是应用排除法,将狐疑有问题的组件正文掉,很快定位到了公司的一个存储服务 jar 包上,又本地进行了一次内存 dump,因为这个 jar 包没有应用 netty 那么它必定应用了 DirectByteBuffer,于是在 VisualVM 中对 dump 进行了剖析,发现DirectByteBuffer 的持有者集中在了存储服务客户端的连贯对象 NioChannel 上,下一步对这个链接对象进行了反编译,搜寻了一下 ByteBuffer#allocateDirect 办法很快发现了一个问题,这个对象初始化的时候申请了 4M 的堆外内存,也就是说每个链接初始化的时候要申请 4M 的堆外内存,于是对咱们线上的服务执行了 jmap -histo 查看对象数统计,发现线上服务 NioChannel 对象多达 1451 个,如下图

大略算了下,每个对象持有 4M 堆外内存,这 1451 个对象要 5804M 将近 6G 的堆外内存,问题一下子清朗了起来,能够判定线上的堆外内存就是这里的问题,顺着代码找过来原来这个链接的 buffer 是能够设置的,分割了存储的同学,对方示意这个 buffer 能够设置小一点,影响不大。为什么只有咱们遇到了这个问题呢,原来是因为咱们的连接数比拟多的缘故,而这个链接数过多的问题其实是咱们的业务起因造成的,并没有改良空间,于是这个问题目前的解决办法也只有调小 buffer。

至此堆外内存使用量过高的问题解决了,那么 fullgc 过多的问题是怎么回事呢,线上的 gc 日志是关上的,拉下来一份看了下,如下图所示:

能够看到一个比拟显著的问题,fgc 之前其实老年代远远没有达到 fgc 的阈值,触发 fgc 的起因是有代码调用了 System.gc(),而咱们并没有刻意设置-XX:+DisableExplicitGC,也不想设置这个参数。那么接下来须要排查哪里进行了System.gc() 调用。
在网上查阅材料时偶尔发现了一个线索这里:初始化 DirectByteBuffer 对象时,在肯定条件下会被动调用System.gc()

查看了 jdk 的源码发现 ByteBuffer#allocateDirect 的过程中的确有一个 System.gc() 的调用,比照上边图 1 的调用栈能够确定是这里触发的 fgc,也就是说 fgc 的问题其实是堆外内存 OOM 的副产品,堆外内存 OOM 的问题解决这个问题也会迎刃而解,至此问题起因排查分明了。

那么为什么老实例和新实例会体现不一样呢,线上的实例并没有呈现 OOM 的谬误日志呢,问题的关键在于存储服务的 client 初始化后便不再变动,新实例初始化时比旧实例的连接数多,恰好达到了 6G 堆外内存下限左近,而 netty 的堆外内存是动静申请的,初始化机会比前者晚,申请进来时再申请堆外内存时没有可用的堆外内存了,触发了 fgc,最终抛出了 OOM。

退出移动版