HeapDump性能社区

性能工具
登录注册
性能文章>SpringCloud Gateway堆外内存溢出排查>

SpringCloud Gateway堆外内存溢出排查转载

大绿植
2年前
609628

生产环境网关模块偶发的 OutOfDirectMemoryError 错误排查起来困难且曲折，2021-02-05号也出现过此问题，起初以为是 JVM 堆内存过小 (当时是 2g) 导致，后调整到8g(2月5号调整)。但是经过上次调整后5月7号又出现此问题，于是猜测可能是由于网关模块存在内存泄露导致。

症状

报错详情

网关模块偶现 OutOfDirectMemoryError 错误，两次问题出现相隔大概 3 个月。两次发生的时机都是正在大批量接收数据 (大约 500w)，TPS 60 左右，网关服务波动不大，完全能扛住，按理不应该出现此错误。

详细报错信息如下：

2021-05-06 13:44:18|WARN |[reactor-http-epoll-5]|[AbstractChannelHandlerContext.java : 311]|An exception 'io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 16384 byte(s) of direct memory (used: 8568993562, max: 8589934592)' [enable DEBUG level for full stacktrace] was thrown by a user handler's exceptionCaught() method while handling the following exception:
io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 16384 byte(s) of direct memory (used: 8568993562, max: 8589934592)
        at io.netty.util.internal.PlatformDependent.incrementMemoryCounter(PlatformDependent.java:754)
        at io.netty.util.internal.PlatformDependent.allocateDirectNoCleaner(PlatformDependent.java:709)
        at io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledUnsafeNoCleanerDirectByteBuf.java:30)
        at io.netty.buffer.UnpooledDirectByteBuf.<init>(UnpooledDirectByteBuf.java:64)
        at io.netty.buffer.UnpooledUnsafeDirectByteBuf.<init>(UnpooledUnsafeDirectByteBuf.java:41)
        at io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.<init>(UnpooledUnsafeNoCleanerDirectByteBuf.java:25)
        at io.netty.buffer.UnsafeByteBufUtil.newUnsafeDirectByteBuf(UnsafeByteBufUtil.java:625)
        at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:359)
        at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:187)
        at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:178)
        at io.netty.channel.unix.PreferredDirectByteBufAllocator.ioBuffer(PreferredDirectByteBufAllocator.java:53)
        at io.netty.channel.DefaultMaxMessagesRecvByteBufAllocator$MaxMessageHandle.allocate(DefaultMaxMessagesRecvByteBufAllocator.java:114)
        at io.netty.channel.epoll.EpollRecvByteAllocatorHandle.allocate(EpollRecvByteAllocatorHandle.java:75)
        at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:777)
        at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:475)
        at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
        at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
        at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
        at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
        at java.lang.Thread.run(Thread.java:748)

JVM 配置

-server -Xmx8g -Xms8g -Xmn1024m 
-XX:PermSize=512m -Xss256k 
-XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled 
-XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m 
-XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly 
-XX:CMSInitiatingOccupancyFraction=70 -Djava.awt.headless=true 
-Djava.net.preferIPv4Stack=true

版本信息

spring cloud : Hoxton.SR5
spring cloud starter gateway : 2.2.3.RELEASE
spring boot starter : 2.3.0.RELEASE
netty : 4.1.54.Final
reactor-netty: 0.9.7.RELEASE

山重水复疑无路

“

JVM 参数详解：https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html

”

报错的信息是 OutOfDirectMemoryError，即堆外内存不足，于是复习了下 JVM 堆外内存的相关知识。

  1. 堆外内存是在 NIO 中使用的；
  2. 堆外内存通过 -XX:MaxDirectMemorySize 参数控制大小，注意和 -XX:+DisableExplicitGC 参数的搭配使用；
  3. JDK8 中堆外内存默认和堆内存一样大（-Xmx）；
  4. JDK8 如果配置 -XX:MaxDirectMemorySize 参数，则堆外内存大小以设置的参数为准；

SpringCloudGateway 是基于 WebFlux 框架实现的，而 WebFlux 框架底层则使用了高性能的 Reactor 模式通信框架 Netty。

网上查阅相关资料，有些场景是因为堆外内存没有手动 release 导致，于是简单查看了网关模块的相关代码发现并无此问题，关键的地方也都调用了相关方法释放内存。堆外内存通过操作堆的命令无法看到，只能监控实例总内存走势判断。

// 释放内存方法
DataBufferUtils.release(dataBuffer);

Dump 堆内存下来也没有发现有什么问题：

柳暗花明又一村

抱着试一试的想法到 SpringCloudGateway 官方仓库 issue 搜索有没有人遇到相同的问题，果不其然，有人提了类似的 issue。

https://github.com/spring-cloud/spring-cloud-gateway/issues/1704

在 issue 中开发人员也给出了回应，确实是 SpringCloudGateway 的 BUG！此问题已在 2.2.6.RELEASE 版本中修复。而我们项目中使用版本为 2.2.3.RELEASE，所以就会出现这个问题。

原因是：包装原生的 pool 后没有释放内存。

出乎意料

问题原因已经找到，想着在测试环境复现后升级版本再验证即可。可结果却出乎了我的意料。

  1. 测试环境将堆内存调小尝试进行复现生产问题，在压测将近 1 个小时后出现了同样的问题，复现成功。
  2. 升级  SpringCloudGateway  的版本至  2.2.6.RELEASE 。
  3. 重新压测，问题再次出现。

你没看错，问题再次出现，且报错信息一模一样。我很快又陷入了沉思。

深究原因

排除了组件的问题，剩下的就是代码的问题了，最有可能的就是程序中没有显示调用释放内存导致。

网关模块共定义了三个过滤器，一个全局过滤器 RequestGatewayFilter implements GlobalFilter。两个自定义过滤器 RequestDecryptGatewayFilterFactory extends AbstractGatewayFilterFactory 和 ResponseEncryptGatewayFilterFactory extends AbstractGatewayFilterFactory。

依次仔细排查相关逻辑，在全局过滤器 RequestGatewayFilter 中有一块代码引起了我的注意：

// 伪代码
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
    HttpHeaders headers = request.getHeaders();
    return DataBufferUtils.join(exchange.getRequest().getBody())
            .flatMap(dataBuffer -> {
                DataBufferUtils.retain(dataBuffer);
                Flux<DataBuffer> cachedFlux = Flux.defer(() -> Flux.just(dataBuffer.slice(0, dataBuffer.readableByteCount())));
                
                ServerHttpRequest mutatedRequest = new ServerHttpRequestDecorator(exchange.getRequest()) {
                    @Override
                    public Flux<DataBuffer> getBody() {
                        return cachedFlux;
                    }

                    @Override
                    public HttpHeaders getHeaders() {
                        return headers;
                    }
                };
                return chain.filter(exchange.mutate().request(mutatedRequest).build());
            });
}

我们知道，Request 的 Body 是只能读取一次的，如果直接通过在 Filter 中读取，而不封装回去回导致后面的服务无法读取数据。

此全局过滤器的目的就是把原有的 request 请求中的 body 内容读出来，并且使用ServerHttpRequestDecorator 这个请求装饰器对 request 进行包装，重写 getBody 方法，并把包装后的请求放到过滤器链中传递下去。这样后面的过滤器中再使用 exchange.getRequest ().getBody () 来获取 body 时，实际上就是调用的重载后的 getBody() 方法，获取的最先已经缓存了的 body 数据。这样就能够实现 body 的多次读取了。

”

但是将 DataBuffer 读取出来后并没有手动释内存，会导致堆外内存持续增长。于是添加了一行代码手动释放堆外内存：

DataBufferUtils.release(dataBuffer);
// 伪代码
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
    HttpHeaders headers = request.getHeaders();
    return DataBufferUtils.join(exchange.getRequest().getBody())
                .flatMap(dataBuffer -> {
                    byte[] bytes = new byte[dataBuffer.readableByteCount()];
                    dataBuffer.read(bytes);
                  // 释放堆外内存
                    DataBufferUtils.release(dataBuffer);
                    ServerHttpRequest mutatedRequest = new ServerHttpRequestDecorator(exchange.getRequest()) {
                        @Override
                        public Flux<DataBuffer> getBody() {
                            return Flux.defer(() -> {
                                DataBuffer buffer = exchange.getResponse().bufferFactory().wrap(bytes);
                                DataBufferUtils.retain(buffer);
                                return Mono.just(buffer);
                            });
                        }

                        @Override
                        public HttpHeaders getHeaders() {
                            return headers;
                        }
                    };
                    return chain.filter(exchange.mutate().request(mutatedRequest).build());
                });
}

再次压测未出现堆外内存溢出问题。终究还是自己大意了。。

后在网络上查询到了类似的案例：

https://github.com/reactor/reactor-netty/issues/788

总结

这个问题排查花费了自己不少的时间，自己也没有想到这么曲折。问题是解决了，但是暴露了自身的很多问题，比如针对不同版本 JVM 内存分配不够熟悉、对 SpringCloudGateway 不够熟悉及太过相信官方开源版本。在直接内存中排查了很久，浪费了不少时间。同时自己也学到了不少东西：

  1. 遇到问题主要先去思考，要全面且细致，慢慢去分析，抽丝剥茧；
  2. 一定要细致再细致，耐心再耐心的去还原问题，思考问题；
  3. JVM 直接内存的使用和配置、场景；
  4. 不要对开源组件过分信任，遇到问题时，对开源组件持怀疑态度；
作者: 彩虹马
链接: http://rainbowhorse.site/命中SpringCloudGateway组件BUG/

文章来源：微信公众号

原文链接：https://mp.weixin.qq.com/s/9e51iYby5TPT8faKXqSHBg

点赞收藏
大绿植
请先登录，查看2条精彩评论吧
快去登录吧，你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流，共同进步
8
2
Lv2
大绿植

徽章

推荐阅读

一次 GDB 源码角度分析 jvm 无响应问题Vue混淆与还原两个例子带你入门 Disruptor13 轻量级锁的重入 以及 线程1获取轻量级锁并释放线程2获取锁 的调试朋友们，就在今天，JDK 21，它终于带着重磅新特性正式发布了！！！为什么 JVM 叫做基于栈的 RISC 虚拟机
站内搜索
Linux
fgc
字节码
堆外内存
火焰图
堆外内存泄漏
java
jvm
gc
linux
内存泄漏
内核

专题推荐

内存泄漏是指无用对象持续占有内存或无用对象的内存得不到及时释放，从而造成内存空间的浪费称为内存泄漏。随着垃圾回收器活动的增加以及内存占用的不断增加，程序性能会逐渐表现出来下降，极端情况下，会引发OutOfMemoryError导致程序崩溃。本期总结了社区所有的内存泄漏实战案例，同样也是干货+实战，帮你攻克内存泄漏问题！
10篇文章24567阅读量

本月精选性能专题

本月精选线上案例

本月精选原创好文

HeapDump

有性能问题，上HeapDump性能社区

Copyright © 2019-2024 heapdump.cn 版权所有 浙ICP备17054444号

联系我们

HeapDump性能社区

网媒渠道

堆堆酱

扫码加堆堆酱好友

友情链接

PerfMa官网SegmentFault思否TesterHomeXPocket开源社区DCloud 问答社区稀土掘金博客园W3CTech