性能提升3倍之路:记Guava cache带来的GC问题

在Spark executor中,由于Guava Cache的使用导致大量GC,分析发现Guava的ConcurrentLinkedQueue$Node造成内存泄漏。问题源于纯读场景下,Guava Cache的recencyQueue清理不及时。解决方案是替换为Caffeine Cache,不仅性能提升,且接口兼容Guava。替换后,GC开销显著降低,执行时间从45分钟缩短到18分钟。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

    问题 

      在用JanusGraph做OLAP分析的项目中,我发现Spark的executor节点出现大量GC,每个executor的GC开销都在task运行时间的10%以上。用JVM async profiler查看后发现,大概40%~50%的CPU时间都花在GC上。尝试G1GC后,现象依旧没有任何改观。

     分析

       只好老老实实做heap dump,但是一直苦于heap dump的结果太大,无法分析。最后从同事那里得知,可以用Memory Analyzer Tool (mat)的脚本去做分析,当然前提也要运行mat的机器有足够的内存,分析的结果是html,可以方便查看。

       打heap dump有专门的命令:

jmap -dump:live,format=b,file=<heap_dump_file> <JVMPID>

       分析heap dump用

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值