IT博文
MySQL 事务隔离级别详解
使用 docker compose 安装 tidb
架构师日记-如何写的一手好代码
生产事故-记一次特殊的OOM排查
Docker安装RabbitMQ——基于docker-compose工具
使用 docker-compose 部署单机 RabbitMQ
只需3步,即刻体验Oracle Database 23c
长达 1.7 万字的 explain 关键字指南!
Redis为什么能抗住10万并发?揭秘性能优越的背后原因
深度剖析Redis九种数据结构实现原理
【绩效季】遇到一个好领导有多重要,从被打差绩效到收获成长
为什么Redis不直接使用C语言的字符串?
Java阻塞队列中的异类,SynchronousQueue底层实现原理剖析
如何调整和优化 Go 程序的内存管理方式?
应用部署引起上游服务抖动问题分析及优化实践方案
Java 并发工具合集 JUC 大爆发!!!
卷起来!!这才是 MySQL 事务 & MVCC 的真相。
JDK8 到 JDK17 有哪些吸引人的新特性?
告别StringUtil:使用Java 11的全新String API优化你的代码
从JDK8飞升到JDK17,再到未来的JDK21
Java JMH Benchmark Tutorial
linux和macOS下top命令区别
Windows10关闭Hyper-V的三种方法
为什么应该选择 POSTGRES?
阿里云对象存储 OSS 限流超过阈值自动关闭【防破产,保平安】
Java高并发革命!JDK19新特性——虚拟线程(Virtual Threads)
“请不要在虚拟机中运行此程序”的解决方案
Spring中的循环依赖及解决
浅谈复杂业务系统的架构设计 | 京东云技术团队
面试题:聊聊TCP的粘包、拆包以及解决方案
操作日志记录实现方式
字节跳动技术团队-慢 SQL 分析与优化
Spring Boot 使用 AOP 防止重复提交
Controller层代码就该这么写,简洁又优雅!
SpringBoot 项目 + JWT 完成用户登录、注册、鉴权
重复提交不再是问题!SpringBoot自定义注解+AOP巧妙解决
SpringBoot 整合 ES 实现 CRUD 操作
SpringBoot 整合 ES 进行各种高级查询搜索
SpringBoot操作ES进行各种高级查询
SpringBoot整合ES查询
如何做架构设计? | 京东云技术团队
最值得推荐的五个VPN软件(便宜+好用+稳定),靠谱的V2ray梯子工具
我说MySQL每张表最好不超过2000万数据,面试官让我回去等通知?
vivo 自研鲁班分布式 ID 服务实践
使用自带zookeeper超简单安装kafka
推荐 6 个很牛的 IDEA 插件
喜马拉雅 Redis 与 Pika 缓存使用军规
「程序员转型技术管理」必修的 10 个能力提升方向
jdk17 下 netty 导致堆内存疯涨原因排查 | 京东云技术团队
如何优雅做好项目管理?
MySQL 到 TiDB:Hive Metastore 横向扩展之路
聊聊即将到来的 MySQL5.7 停服事件
Linux终端环境配置
微软 Edge 浏览器隐藏功能一览:多线程下载、IE 模式、阻止视频自动播放等
Hutool 中那些常用的工具类和实用方法
clash 内核删库?汇总目前常用的内核仓库和客户端
JDK11 升级 JDK17 最全实践干货来了 | 京东云技术团队
我是如何写一篇技术文的?
虚拟线程原理及性能分析
Java线程池实现原理及其在美团业务中的实践
Editplus和EmEditor配置一键编译java运行环境
用Spring Boot 3.2虚拟线程搭建静态文件服务器有多快?
SpringBoot中使用LocalDateTime踩坑记录 - 程序员偏安 - 博客园
程序员必备!10款实用便捷的Git可视化管理工具 - 追逐时光者 - 博客园
基于Netty开发轻量级RPC框架
开发Java应用时如何用好Log
复杂SQL治理实践 | 京东物流技术团队
火山引擎ByteHouse:分析型数据库如何设计并发控制?
多次崩了之后,阿里云终于改了
推荐程序员必知的四大神级学习网站
初探分布式链路追踪
新项目为什么决定用 JDK 17了
Java上进了,JDK21 要来了,并发编程再也不是噩梦了
mapstruct这么用,同事也开始模仿
再见RestTemplate,Spring 6.1新特性:RestClient 了解一下!
【MySQL】MySQL表设计的经验(建议收藏)
如何正确地理解应用架构并开发
解读工行专利CN112905176B
工商银行取得「基于 Spring Boot 的 web 系统后端实现方法及装置」专利
IDEA 2024.1:Spring支持增强、GitHub Action支持增强、更新HTTP Client等
TIOBE 2 月:Go 首次进入前十、“上古语言” COBOL 和 Fortran 排名飙升
Java 21 虚拟线程如何限流控制吞吐量
🎉 通用、灵活、高性能分布式 ID 生成器 | CosId 2.6.6 发布
20年编程,AI编程6个月,关于Copliot辅助编码工具,你想知道的都在这里
Java 8 内存管理原理解析及内存故障排查实践
消息队列选型之 Kafka vs RabbitMQ
从 MongoDB 到 PostgreSQL 的大迁移
腾讯云4月8日故障复盘及情况说明
PHP 在 2024 年还值得学习吗?
AMD集显安装显卡驱动之后出现黑屏,建议这样解决
使用 Docker 部署 moments 微信朋友圈 - 谱次· - 博客园
Java 17 是最常用的 Java LTS 版本
盘点Lombok的几个骚操作
Llama 3 + Ollama + Open WebUI打造本机强大GPT
如何优雅地编写缓存代码
Gmeek快速上手
笔记软件思源远程和本地接入大语言模型服务Ollama实现AI辅助写作(Windows篇)
Git Subtree:简单粗暴的多项目管理神器
这款轻量级规则引擎,真香!!
Ollama教程:本地LLM管理、WebUI对话、Python/Java客户端API应用
GLM-4-9B支持 Ollama 部署
智谱AI开源代码生成大模型第四代版本:CodeGeeX4-ALL-9B
美团二面:如何保证Redis与Mysql双写一致性?连续两个面试问到了!
免费开源好用,Obsidian和Omnivore真正实现一键联动剪藏文章,手把手教程!
得物 Redis 设计与实践
架构图怎么画?手把手教您,以生鲜电商为例剖析业务/应用/数据/技术架构图
使用Hutool要注意了!升级到6.0后你调用的所有方法都将报错 - 掘金
别再用雪花算法生成ID了!试试这个吧
无敌的Arthas!
Navicat Premium v16、v17 破解激活
🎉 分布式接口文档聚合,Solon 是怎么做的?
深入体验全新 Cursor AI IDE 后,说杀疯了真不为过!
Nacos 3.0 架构全景解读,AI 时代服务注册中心的演进
本文档使用 MrDoc 发布
-
+
jdk17 下 netty 导致堆内存疯涨原因排查 | 京东云技术团队
# 背景: ### 介绍 天网风控**灵玑**系统是基于内存计算实现的高吞吐低延迟在线计算服务,提供滑动或滚动窗口内的 count、distinctCout、max、min、avg、sum、std 及区间分布类的在线统计计算服务。客户端和服务端底层通过 netty 直接进行 tcp 通信,且服务端也是基于 netty 将数据备份到对应的 slave 集群。  ### 低延迟的瓶颈 灵玑第 1 个版本经过大量优化,系统能提供较大的吞吐量。如果对客户端设置 10ms 超时,服务端 1wqps/core 的流量下,可用率只能保证在 98.9% 左右,高并发情况下主要是 gc 导致可用率降低。如果基于 cms 垃圾回收器。当一台 8c16g 的机器在经过第二个版本优化后吞吐量超过 20wqps 的时候,那么大概每 4 秒会产生一次 gc。如果按照一次 gc 等于 30ms。那么至少分钟颗粒度在 gc 时间的占比至少在 (15\*30/1000/60)=0.0075。也就意味着分钟级别的 tp992 至少在 30ms。不满足相关业务的需求。 ### jdk17+ZGC 为了解决上述延迟过高的相关问题,JDK 11 开始推出了一种低延迟垃圾回收器 ZGC。ZGC 使用了一些新技术和优化算法,可以将 GC 暂停时间控制在 10 毫秒以内,而在 JDK 17 的加持下,ZGC 的暂停时间甚至可以控制在亚毫秒级别。实测在平均停顿时间在 10us 左右,主要是基于一个染色指针和读屏障做到大多数 gc 阶段可以做到并发的,有兴趣的同学可以了解下,并且 jdk17 是一个 lts 版本。 # 问题: 采用 jdk17+zgc 经过相关的压测后,一切都在向着好的方向发展,但是在一种特殊场景压测,需要将数据从北京数据中心同步给宿迁数据中心的时候,发现了一些诡异的事情 - 服务端容器的内存疯涨,并且停止压测后,内存只是非常缓慢的减少。 - 相关机器 cpu 一直保存在 20%(已经无流量请求) - 一直在次数不多的 gc。大概每 10s 一次  # 排查之旅 ### 内存泄漏排查 第一反应是遇到内存疯涨和无法释放该问题时,首先归纳为内存泄漏问题,感觉这题也简单明了。开始相关内存泄漏检查:先 dump 堆内存分析发现占用堆内存的是 netty 相关的对象,恰好前段时间也有个同学也分享了 netty 下的不合理使用 netty byteBuf 导致的内存泄漏,进一步增加了对 netty 内存泄露的怀疑。 于是开启 netty 内存泄漏严格检查模式 (加上 jvm 参数 Dio.netty.leakDetection.level=PARANOID),重新试跑并没有发现相关内存泄漏日志。好吧~!初步判定不是 netty 内存泄漏。  ### jdk 与 netty 版本 bug 排查 会不会是 netty 与 jdk17 兼容不好导致的 bug? 回滚 jdk8 测试发现的确不存在这个问题,当时使用的是 jdk17.0.7 版本。正好官方发布了 jdk17.0.8 版本,并且看到版本介绍上有若干的 Bug Fixes。所以又升级了 jdk 一个小版本,然而发现问题仍然在。会不会是 netty 的版本过低?正好看见 gitup 上也有类似的 issue# [https://github.com/netty/netty/issues/6125WriteBufferWaterMark's](https://www.oschina.net/action/GoToLink?url=https%3A%2F%2Fgithub.com%2Fnetty%2Fnetty%2Fissues%2F6125WriteBufferWaterMark%27s) 并且在高版本疑似修复了该问题,修改了 netty 几个版本重新压测,然而发现问题仍然在。 ### 直接原因定位与解决 经过上述两次排查,发现问题比想象中复杂,应该深入分析下为什么,重新梳理了下相关线索: - 发现回滚至 jdk8 的时候,对应宿迁中心的集群接受到的备份数据量比北京中心发送的数据量低了很多 - 为什么没有流量了还一直有 gc,cpu 高应该是 gc 造成的(当时认为是 zgc 的内存的一些特性) - 内存分析:为什么 netty 的 MpscUnboundedArrayQueue 引用了大量的 AbstractChannelHandlerContext$WriteTask 对象,。MpscUnboundedArrayQueue 是生产消费 writeAndFlush 任务队列,WriteTask 是相关的 writeAndFlush 的任务对象,正是因为大量的 WriteTask 对象及其引用导致了内存占用过高。 - 只有跨数据中心出现该问题,同数据中心数据压测不会出现该问题。 分析过后已经有了基本的猜想,因为跨数据中心下机房延迟更大,单 channel 信道下已经没法满足同步数据能力,导致 netty 的 eventLoop 的消费能不足导致积压。 解决方案:增加与备份数据节点的 channel 信道连接,采用 connectionPool,每次批量同步数据的时候随机选择一个存活的 channel 进行数据通信。经过相关改造后发现问题得到了解决。 ### 根因定位与解决 #### 根因定位 虽然经过上述的改造,表面上看似解决了问题,但是问题的根本原因还是没有被发现 - 1\. 如果是 eventLoop 消费能力不足,为什么停止压测后,相关内存只是缓慢减少,按理说应该是疯狂的内存减少。 - 2\. 为什么一直 cpu 在 23% 左右,按照平时的压测数据,同步数据是一个流转批的操作,最多也就消耗 5% cpu 左右,多出来的 cpu 应该是 gc 造成的,但是数据同步应该并不多,不应该造成这么多的 gc 压力。 - 3\. 为什么 jdk8 下不会存在该问题 推测应该是有个 netty eventLoop 消费耗时阻塞的操作导致消费能力大幅度下降。所以感觉还是 netty 的问题,于是开了 netty 的相关 debug 日志。发现了一行关键日志 ``` [2023-08-23 11:16:16.163] DEBUG [] - io.netty.util.internal.PlatformDependent0 - direct buffer constructor: unavailable: Reflective setAccessible(true) disabled ``` 顺着这条日志找到了本次的问题根因,为什么一个直接内存的构造器不能使用会导致我们系统 WriteTask 消费阻塞, 带着这个目的去查看相关的源码。 #### 源码分析 - 一) netty 默认会用 PooledByteBufAllocator 来分配直接内存,采用类似 jmelloc 的内存池机制,每次内存不足的时候会通过创建 io.netty.buffer.PoolArena.DirectArena#newChunk 去预占申请内存。 ``` protected PoolChunk<ByteBuffer> newChunk() { // 关键代码 ByteBuffer memory = allocateDirect(chunkSize); } } ``` - 二) allocateDirect () 是申请直接内存的逻辑。大致就是如果能采用底层 unsafe 去申请、释放直接内存和反射创建 ByteBuffer 对象,那么就采用 unsafe。否则就直接调用 java 的 Api ByteBuffer.allocateDirect 来直接分配内存并且采用自带的 Cleaner 来释放内存。这里 PlatformDependent.useDirectBufferNoCleaner 是个关键点,其实就是 USE\_DIRECT\_BUFFER\_NO\_CLEANER 参数配置 ``` PlatformDependent.useDirectBufferNoCleaner() ? PlatformDependent.allocateDirectNoCleaner(capacity) : ByteBuffer.allocateDirect(capacity); ``` - 三) USE\_DIRECT\_BUFFER\_NO\_CLEANER 参数逻辑配置在 PlatformDependent 类的 static {} 里面。 关键逻辑:maxDirectMemory==0 和!hasUnsafe () 在 jdk17 下没有特殊配置都是不满足条件的,关键是 PlatformDependent0.hasDirectBufferNoCleanerConstructor 的判断逻辑 ``` if (maxDirectMemory == 0 || !hasUnsafe() || !PlatformDependent0.hasDirectBufferNoCleanerConstructor()) { USE_DIRECT_BUFFER_NO_CLEANER = false; } else { USE_DIRECT_BUFFER_NO_CLEANER = true; ``` - 四) PlatformDependent0.hasDirectBufferNoCleanerConstructor () 的判断是看 PlatformDependent0 的 DIRECT\_BUFFER\_CONSTRUCTOR 是否 NULL,回到了刚开的 debug 日志,我们是可以看到在默认情况下 DIRECT\_BUFFER\_CONSTRUCTOR 该构造器是 unavailable 的(unavailable 则为 NULL)。以下代码具体的逻辑判断及其伪代码。 1\. 开启条件一:jdk9 及其以上必须要开启 jvm 参数 -io.netty.tryReflectionSetAccessible 参数 2\. 开启条件二:能反射获取到一个 private DirectByteBuffer 构造器,该构造器是通过内存地址和大小来构造 DirectByteBuffer.(备注:如果在 jdk9 以上对 java.nio 有模块权限限制,需要加上 jvm 启动参数 --add-opens=java.base/java.nio=ALL-UNNAMED , 否则会报 Unable to make private java.nio.DirectByteBuffer (long,int) accessible: module java.base does not "opens java.nio" to unnamed module) 所以这里我们默认是没有开启这两个 jvm 参数的,那么 DIRECT\_BUFFER\_CONSTRUCTOR 为空值,对应第二部 PlatformDependent.useDirectBufferNoCleaner () 为 false。 ``` // 伪代码,实际与这不一致 ByteBuffer direct = ByteBuffer.allocateDirect(1); if(SystemPropertyUtil.getBoolean("io.netty.tryReflectionSetAccessible", javaVersion() < 9 || RUNNING_IN_NATIVE_IMAGE)) { DIRECT_BUFFER_CONSTRUCTOR = direct.getClass().getDeclaredConstructor(long.class, int.class) } ``` - 五) 现在回到第 2 步骤,发现 PlatformDependent.useDirectBufferNoCleaner () 在 jdk 高版本下默认值是 false。那么每次申请直接内存都是通过 ByteBuffer.allocateDirect 来创建。那么到这个时候就已经**定位**到相关根因了,通过 ByteBuffer.allocateDirect 来申请直接内存,如果内存不足的时候会强制系统 System.Gc (),并且会同步等待 DirectByteBuffer 通过 Cleaner 的虚引用回收内存。下面是 ByteBuffer.allocateDirect 预占内存(reserveMemory)的关键代码。大概逻辑是 触达申请的最大的直接内存 -> 判断是否有相关的对象在 gc 回收 -> 没有在回收则主动触发 System.gc () 来触发回收 -> 在同步循环最多等待 MAX\_SLEEPS 次数看是否有足够的直接内存。整个同步等待逻辑在亲测在 jdk17 版本最多能 1 秒以上。 所以最根本原因:**如果这个时候我们的 netty 的消费者 EventLoop 处理消费因为申请直接内存在达到最大内存的场景,那么就会导致有大量的任务消费都会同步去等待申请直接内存上。并且如果没有足够的的直接内存,那么就会成为大面积的消费阻塞。** ``` static void reserveMemory(long size, long cap) { if (!MEMORY_LIMIT_SET && VM.initLevel() >= 1) { MAX_MEMORY = VM.maxDirectMemory(); MEMORY_LIMIT_SET = true; } // optimist! if (tryReserveMemory(size, cap)) { return; } final JavaLangRefAccess jlra = SharedSecrets.getJavaLangRefAccess(); boolean interrupted = false; try { do { try { refprocActive = jlra.waitForReferenceProcessing(); } catch (InterruptedException e) { // Defer interrupts and keep trying. interrupted = true; refprocActive = true; } if (tryReserveMemory(size, cap)) { return; } } while (refprocActive); // trigger VM's Reference processing System.gc(); int sleeps = 0; while (true) { if (tryReserveMemory(size, cap)) { return; } if (sleeps >= MAX_SLEEPS) { break; } try { if (!jlra.waitForReferenceProcessing()) { Thread.sleep(sleepTime); sleepTime <<= 1; sleeps++; } } catch (InterruptedException e) { interrupted = true; } } // no luck throw new OutOfMemoryError ("Cannot reserve " + size + " bytes of direct buffer memory (allocated: " + RESERVED_MEMORY.get() + ", limit: " + MAX_MEMORY +")"); } finally { if (interrupted) { // don't swallow interrupts Thread.currentThread().interrupt(); } } } ``` - 六) 虽然我们看到了阻塞的原因,但是为什么 jdk8 下为什么就**不会阻塞**从 4 步骤中看到 java 9 以下是设置了 DIRECT\_BUFFER\_CONSTRUCTOR 的,因此采用的是 PlatformDependent.allocateDirectNoCleaner 进行内存分配。 以下是具体的介绍和关键代码 步骤一:申请内存前:通过全局内存计数器 **DIRECT\_MEMORY\_COUNTER**,在每次申请内存的时候调用 incrementMemoryCounter 增加相关的 size,如果达到相关 DIRECT\_MEMORY\_LIMIT (默认是 - XX:MaxDirectMemorySize) 参数则**直接抛出异常**,而不会去同步 gc 等待导致大量耗时。。 步骤二:**分配内存 allocateDirectNoCleaner**: 是通过 unsafe 去申请内存,再用构造器 **DIRECT\_BUFFER\_CONSTRUCTOR** 通过内存地址和大小来构造 DirectBuffer。释放也可以通过 unsafe.freeMemory 根据内存地址来释放相关内存,而不是通过 java 自带的 cleaner 来释放内存。 ``` public static ByteBuffer allocateDirectNoCleaner(int capacity) { assert USE_DIRECT_BUFFER_NO_CLEANER; incrementMemoryCounter(capacity); try { return PlatformDependent0.allocateDirectNoCleaner(capacity); } catch (Throwable e) { decrementMemoryCounter(capacity); throwException(e); return null; } } private static void incrementMemoryCounter(int capacity) { if (DIRECT_MEMORY_COUNTER != null) { long newUsedMemory = DIRECT_MEMORY_COUNTER.addAndGet(capacity); if (newUsedMemory > DIRECT_MEMORY_LIMIT) { DIRECT_MEMORY_COUNTER.addAndGet(-capacity); throw new OutOfDirectMemoryError("failed to allocate " + capacity + " byte(s) of direct memory (used: " + (newUsedMemory - capacity) + ", max: " + DIRECT_MEMORY_LIMIT + ')'); } } } static ByteBuffer allocateDirectNoCleaner(int capacity) { return newDirectBuffer(UNSAFE.allocateMemory(Math.max(1, capacity)), capacity); } ``` - 经过上述的源码分析,已经看到了根本原因,就是 ByteBuffer.allocateDirect gc 同步等待直接内存释放导致消费能力严重不足导致的,并且在最大直接内存不足的情况下,大面积的消费阻塞耗时在申请直接内存,导致消费 WriteTask 能力接近于 0,内存从而无法下降 # 总结 1\. 流程图:  2\. 直接原因: - 跨数据中心同步数据单 channel 管道同步数据能力不足,导致 tcp 环阻塞。从而导致 netty eventLoop 的消费 WriteTask 任务 (WriteAndFlush) 中的 write 能力大于 flush 能力,因此申请的大量的**直接内存**存放在 ChannelOutboundBuffer#unflushedEntry 链表中没法 flush。 3\. 根本原因: - netty 在 jdk 高版本需要手动添加 jvm 参数 -add-opens=java.base/java.nio=ALL-UNNAMED 和 - io.netty.tryReflectionSetAccessible 来开启采用直接调用底层 unsafe 来申请内存,如果不开启那么 netty 申请内存采用 ByteBuffer.allocateDirect 来申请直接内存,如果 EventLoop 消费任务申请的直接内存达到最大直接内存场景,那么就会导致有大量的任务消费都会同步去等待申请直接内存上。并且如果没有释放足够的直接内存,那么就会成为大面积的消费阻塞,也同时导致大量的对象累积在 netty 的无界队列 MpscUnboundedArrayQueue 中。 4\. 反思与定位问题慢的原因: - 默认同步数据这里不会是系统瓶颈,没有加上 lowWaterMark 和 highWaterMark 水位线的判断(socketChannel.isWritable ()),如果同步数据达到系统瓶颈应该提前能感知到抛出异常。 - 同步数据的时候调用 writeAndFlush 应该加上相关的异常监听器(以下代码 2),若果能提前感知到异常 OutOfMemoryError 那么更方便排查到相关问题。 ``` (1)ChannelFuture writeAndFlush(Object msg) (2)ChannelFuture writeAndFlush(Object msg, ChannelPromise promise); ``` - jdk17 下监控系统看到的**非堆内存监控**并未与**系统实际使用的直接内存**统计一致,导致开始定位问题无法定位到直接内存已经达到最大值,从而并未往这个方案思考。 - 相关引用的**中间件底层通信也是依赖于 netty 通信**,如果有类似的数据同步也可能会触发类似的问题。特别 ump 在高版本和 titan 使用 netty 的时候是进行了 shade 打包的,并且相关的 jvm 参数也被修改,虽然不会触发该 bug,但是也可能导致触发系统 gc。 ``` ump高版本:jvm参数修改(低版本直接采用了底层socket通信,未使用netty和创建ByteBuffer) io.netty.tryReflectionSetAccessible->ump.profiler.shade.io.netty.tryReflectionSetAccessible titan:jvm参数修改:io.netty.tryReflectionSetAccessible->titan.profiler.shade.io.netty.tryReflectionSetAccessible ``` > 作者:京东零售 刘鹏 > > 来源:京东云开发者社区 转载请注明来源
admin
2023年9月9日 05:40
转发文档
收藏文档
上一篇
下一篇
手机扫码
复制链接
手机扫一扫转发分享
复制链接
Markdown文件
PDF文档(打印)
分享
链接
类型
密码
更新密码