Netty 内存管理: PooledByteBufAllocat

作者: isdom | 来源:发表于2017-01-28 18:13 被阅读1560次

我们当前的生产系统是典型的微服务架构,其中的关键部分API网关 xharbor 自2014年初开始研发并在 github 上开源。 xharbor 中的网络层基于 netty ,而架构上重度使用 rxjava 定义模块间的响应式接口。xharbor 需要根据业务规则转发客户端的请求(request)到特定的后端服务,在后端服务处理完成后再将响应(response)发送回客户端,而在转发前后可能还需要进行请求/响应的重写。因此,有效的内存使用对 xharbor 的性能、稳定性和扩展性至关重要。在 xharbor 开发时,我们首先关注的是 netty 的内存管理和泄漏检测。

netty 架构图 —— 摘自 http://netty.io
在上面的 netty 架构图中,可以看到 "Zero-Copy-Capable Rich Byte Buffer"是其核心部分的坚固基石。而内存管理又是这一技术的重点。netty 内存管理的高性能主要依赖于两个关键点:
  • 内存的池化管理
  • 使用堆外直接内存(Direct Memory)

堆外直接内存的优势:Java 网络程序中使用堆外直接内存进行内容发送(Socket读写操作),可以避免了字节缓冲区的二次拷贝;相反,如果使用传统的堆内存(Heap Memory,其实就是byte[])进行Socket读写,JVM会将堆内存Buffer拷贝一份到堆外直接内存中,然后才写入Socket中。这样,相比于堆外直接内存,消息在发送过程中多了一次缓冲区的内存拷贝。

而池化管理带来的性能提升参见下图,引用自Why Netty (by Norman Maurer at Netflix)

https://blog.twitter.com/2013/netty-4-at-twitter-reduced-gc-overhead
如上图图例所展示的, netty 基于两个维度:池化/非池化、Heap Memory/Direct Memory 的组合来确定最终使用的内存管理策略。对 netty 应用首先要能确定netty 到底采用了哪种内存管理策略,才能对各种情况下的性能表现有预期。根据 ByteBufUtil 代码:
    String allocType = SystemPropertyUtil.get(
            "io.netty.allocator.type", 
            PlatformDependent.isAndroid() ? "unpooled" : "pooled");
    allocType = allocType.toLowerCase(Locale.US).trim();

    ByteBufAllocator alloc;
    if ("unpooled".equals(allocType)) {
        alloc = UnpooledByteBufAllocator.DEFAULT;
        logger.debug("-Dio.netty.allocator.type: {}", allocType);
    } else if ("pooled".equals(allocType)) {
        alloc = PooledByteBufAllocator.DEFAULT;
        logger.debug("-Dio.netty.allocator.type: {}", allocType);
    } else {
        alloc = PooledByteBufAllocator.DEFAULT;
        logger.debug("-Dio.netty.allocator.type: pooled (unknown: {})", allocType);
    }

需要在 netty 应用启动时,设置 JVM参数 -Dio.netty.allocator.type=pooled 设置池化管理策略,而根据 PlatformDependent 中的代码片段:

private static final boolean DIRECT_BUFFER_PREFERRED =
        HAS_UNSAFE && !SystemPropertyUtil.getBoolean(
        "io.netty.noPreferDirect", false);

只要没有设置 -Dio.netty.noPreferDirect=true 并且运行在标准 Oracle JVM(sun.misc.Unsafe存在)中,就会优先使用 Direct Memory,当然还有一个前提是分配了一定数量的Direct Memory,本着省着过日子的想法,一开始 xharbor 中设定了64M的Direct Memory大小,-XX:MaxDirectMemorySize=64M,此时和 netty 相关的 JVM 启动参数为:

    -XX:MaxDirectMemorySize=64M
    -Dio.netty.allocator.type=pooled

运行 xharbor ,通过特定日志输出观察用于Socket读写的 ByteBuf 实例,如下截图所示:

xharbor 运行日志截图
WTF! 不看不知道,一看吓一跳,怎么会是 Unpooled 类型的ByteBuf。反复检查了几次启动参数,确认无误。好吧,Talk is cheap,Show me the code代码是检验一切的标准。找到 PooledByteBufAllocator.newDirectBuffer,摘录如下:
protected ByteBuf newDirectBuffer(int initialCapacity, int maxCapacity) {
    PoolThreadCache cache = threadCache.get();
    PoolArena<ByteBuffer> directArena = cache.directArena;

    ByteBuf buf;
    if (directArena != null) {
        buf = directArena.allocate(cache, initialCapacity, maxCapacity);
    } else {
        if (PlatformDependent.hasUnsafe()) {
            buf = UnsafeByteBufUtil.newUnsafeDirectByteBuf(this, initialCapacity, maxCapacity);
        } else {
            buf = new UnpooledDirectByteBuf(this, initialCapacity, maxCapacity);
        }
    }

    return toLeakAwareBuffer(buf);
}

在上面的代码逻辑中,当 directArena 为空时,会直接产生 Unpooled 类型的ByteBuf。难道是 directArena 为空导致的?netty 启动时会详细输出各项配置,翻找之下,果然有所发现:

netty 启动时的日志输出
DirectMemory 的 Arena 数量为0,难怪 directArena 为空。继续在 PooledByteBufAllocator 的代码中查找原因,寻获相关代码片段如下:
    final int defaultMinNumArena = runtime.availableProcessors() * 2;
    final int defaultChunkSize = DEFAULT_PAGE_SIZE << DEFAULT_MAX_ORDER;
    ......
    DEFAULT_NUM_DIRECT_ARENA = Math.max(0,
            SystemPropertyUtil.getInt(
                    "io.netty.allocator.numDirectArenas",
                    (int) Math.min(
                            defaultMinNumArena,
                            PlatformDependent.maxDirectMemory() 
                            / defaultChunkSize / 2 / 3)));

常量 DEFAULT_PAGE_SIZEDEFAULT_MAX_ORDER 在没有特别设置的情况下,缺省值分别为 8192 和 11,因此, defaultChunkSize 的缺省大小是 8192 << 11 = 16M。根据上面的代码,PlatformDependent.maxDirectMemory() 得大于等于 16M * 2 * 3 = 96M 才能使 DEFAULT_NUM_DIRECT_ARENA =1。因此,调整 xharbor 的JVM 启动参数为:

    -XX:MaxDirectMemorySize=96M
    -Dio.netty.allocator.type=pooled
netty 启动时的日志输出(2)
从 xharbor 启动日志中的 netty 初始化信息看到,总算有了一个 DirectMemory Arena 。再次通过 xharbor 日志输出观察用于Socket读写的 ByteBuf 实例,这次总算是 Pooled 类型的 DirectByteBuf。
xharbor 运行日志截图(2)
通过上面的代码探险,xharbor 总算有了一个不错的开始,我们通过设置适当的 DirectMemory 大小(>=96M)和内存管理策略(io.netty.allocator.type=pooled)使得 xharbor 用上了池化的堆外直接内存。但在一个高并发、重负载系统中,一旦出现内存泄漏,往往就意味着系统崩溃这样的致命问题,具体到 netty 中的ByteBuf,由于它使用了引用计数方式管理生命周期,使得问题排查更为复杂。那么:
  • 如何才能及时无误的查看 xharbor 中是否存在泄漏?
  • **netty 中有什么的便利的设施供我们使用吗? **

让我们把问题留到本系列的下一篇吧!


本系列:

  1. Netty 内存管理探险: PoolArena 分配之谜
  2. Netty 内存管理探险: PoolArena 统计之BUG和解决

参考

相关文章

  • Netty 内存管理: PooledByteBufAllocat

    我们当前的生产系统是典型的微服务架构,其中的关键部分API网关 xharbor 自2014年初开始研发并在 git...

  • Netty内存模型-PoolChunk

    1概述 从netty 4开始,netty加入了内存池管理,采用内存池管理比普通的new ByteBuf性能提高了数...

  • Netty源码分析

    最近完成了Netty源码分析,希望可以和大家共同交流 Netty Recycler源码解析Netty 内存管理源码...

  • 8.池化内存分配

    netty内存管理思想 PooledByteBufAllocate PoolChunkChunk初始化PoolCh...

  • Netty 内存管理

    Netty中有一个主要的特点,就是ByteBuf的实现, 由于NIO中java.nio.ByteBuf中只有pos...

  • Netty内存管理

    概述 Netty使用ByteBuf作为其底层数据传输的容器,其实现有两种方式:基于堆内存与基于直接内存。为了减少传...

  • Netty 内存管理探险: PoolArena 分配之谜

    在本系列的上一篇《Netty 内存管理: PooledByteBufAllocator & PoolArena 代...

  • netty内存分析

    netty内存规格 netty内存分配器类图如下 我们直接看io.netty.buffer.PooledByteB...

  • netty与内存分配(2)-PooledByteBufAlloc

    简介 在java已经实现了通过jvm对内存空间的管理后,netty为什么还需要进行内存分配管理?因为jvm管理的内...

  • Netty-内存管理

    但是内存拷贝对性能有可能影响比较大,所以Java中可以绕开堆内存直接操作堆外内存,问题是创建堆外内存的速度比堆内存...

网友评论

    本文标题:Netty 内存管理: PooledByteBufAllocat

    本文链接:https://www.haomeiwen.com/subject/aueqittx.html