jvm性能调优实战 - 34十万QPS的社交APP 如何优化GC性能提升3倍?

简介: jvm性能调优实战 - 34十万QPS的社交APP 如何优化GC性能提升3倍?

Pre

这篇文章开始,我们会开始用一系列真实的生产案例给大家还原出来各种各样不同的JVM优化场景

力求让大家在不同的业务背景下,对不同的原因产生的JVM性能问题进行分析和处理,进而积累出来大量不同场景下的JVM性能优化经验。

所有的JVM优化案例都是基于之前几十篇文章教给大家的核心原理以及优化手段来展开的,因此大家可以认为,之前几十篇文章学习完过后,你就已经有能力在生产系统上手进行JVM的性能分析以及优化了。

只不过大家如果再经过几十个真实的生产案例的锤炼,就能够有能力对未来自己可能遇到的各种不同的情况下的JVM生产问题进行分析和处理。

因为这些案例都是真实的生产案例,所以有的案例我们会用一些模拟代码还原出来当时的故障场景,并且带着大家用各种工具来进行分析,然后进行优化。

但是有的案例我们很难用模拟代码还原出来,此时还会延续采用一步一图的方式,尽量用大量的手绘图让大家理解JVM故障的产生背景、发生原因以及优化的手段。

跟之前一样,我们开始先用两三个较为简单的案例引入,让大家找找感觉,接着再切入比较复杂的案例。


案例背景

本案例的背景是一个有高峰期每秒十万QPS的社交APP, 大家都知道,其实现在社交APP有很多种,不光是大家熟悉的微信、QQ之类的,还有很多细分领域的明星社交APP,诸如陌生人社交,基于地理位置的社交,等等。

其实很多明星创业社交APP产品,也有每日数百万的日活用户,尤其在晚上高峰期的时候,APP的QPS也是很高的。

附带一句,可能有的同学不知道QPS是什么,其实英文全称就是“Query Per Second”,也就是每秒钟的查询数量,大致可以理解为是APP每秒钟的访问数量。

对于这个APP而言,流量最大的是哪个功能模块?

不知道大家有没有玩儿过陌生人社交类的APP,在这种APP中操作最多的就是浏览某个陌生人的个人页面。

一般这类APP都会通过各种方式来给你推荐一些周边的陌生人,然后你可能会看到一些感兴趣的人,就会进入他/她的个人主页去看一看。个人主页里可能就包含了那个人的一些自我介绍,照片之类的东西。

所以这类APP,在晚上高峰期,流量最大的一个模块,其实就是个人主页模块

会有大量的活跃用户在一个集中的时间段内频繁的访问各种个人主页数据,而且这类数据的量还通常很大,要包含很多的信息,通常一个个人主页的数据甚至可能有几MB。

随便给大家举个例子,一个个人主页里,可能有这个人每天发的一些心情、感悟之类的东西

那么一旦要把这个个人主页加载出来,必然会加载出来这个人最近N多天发的一些心情感悟之类的文字,这个文字的量还是比较多的。

所以我们大致可以认为,一次个人主页的查询,就会加载出来比如5MB的数据。

而且一般在高峰期内,有可能一些活跃用户他可能会连续不断的去点击他感兴趣的人的个人主页,比如连续1个小时都在不停的点击。

所以其实这类社交APP他的高峰期QPS时很高的。在当时的场景中,这个社交APP流量最大的个人主页模块高峰期最多每秒会有10万+的QPS。

当然在底层存储中,这些个人主页数据一定是基于缓存来存放的,也就是基于Redis缓存来查询这些个人主页数据。

所以,综合我们分析出来的这个背景,我们在这里可以用下面一幅图来让大家了解一下这个社交APP的一个情况。


高并发查询导致对象快速进入老年代

之前已经用大量的图示给大家分析过了JVM的运行原理了,所以在这个案例中就不再给大家描述的过于细节。

这里就直接给大家分析一下当时案例发生的一个场景,因为这个社交APP的日活用户涨的很快,所以导致他的高峰期QPS很快就飙升到了10万。

正是因为每秒并发量太高,这也直接导致了这个系统在高峰期的时候,年轻代的Eden区会迅速的被填满,并且频繁的触发Young GC,如下图所示。

而且每次在Young GC的时候,实际上还有很多请求是没处理完毕的,没办法,因为每秒请求量太多了,所以在你触发Young GC的时候,就这一瞬间,必然有很多请求是还没处理完毕的。

这就导致Eden区中其实每次触发Young GC的时候,都有很多对象是需要存活下来的

如下图所示:

因此在高峰期的时候,其实经常会出现Young GC过后存活对象较多,在Survivor区中放不下的问题,如下图所示。

所以此时必然会导致大量的对象快速的进入老年代中,如下图所示。


老年代必然会触发频繁GC

其实根据之前学过的知识,大家都清楚了一点,那就是一旦在高并发场景下Young GC后存活对象过多,导致对象快速进入老年代,必然会频繁触发老年代的GC,对老年代进行垃圾回收。

所以在上述社交APP高峰期高并发场景下,必然会导致个人主页服务对应的JVM频繁的发生老年代的GC,如下图所示。


优化前的线上系统JVM参数

其实大家都知道,针对上述场景,最核心的优化点,主要应该是增加机器,尽量让每台机器承载更少的并发请求,减轻压力。

同时,给年轻代的Survivor区域更大的内存空间,让每次Young GC后的存活对象务必停留在Survior中,别进入老年代。

但是在这里我们先不考虑上述优化,在优化前的线上系统中,对JVM有两个比较关键的参数大家可以看一下:

-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=5

大家可以看到这个是什么意思,其实非常明显,我们之前讲过这两个参数的含义。CMS垃圾回收器默认是采用标记-清理算法,所以是会造成大量的内存碎片的。

什么叫内存碎片?我们再来看下图回顾一下

比如现在老年代内存里有一些垃圾对象。

然后CMS垃圾回收器一次垃圾回收过后,回收掉了一些垃圾对象,此时可能内存里看起来跟下面这样:

大家注意上面那个红圈的地方,因为回收掉了一个对象,所以那里出现了一个内存碎片

虽然这里是空白内存,但是假如此时你要是要分配一个对象比较大,没法再上面红圈处放进去呢?那么红圈的那个内存碎片不就没任何意义了?

所以CMS正常垃圾回收,因为使用标记-清理算法,所以必然导致大量的内存碎片。

所以“-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=5”两个参数的含义,就是在5次Full GC之后会触发一次Compaction操作,也就是压缩操作

这个操作会把存活对象放到紧邻在一起,避免大量的内存碎片,如下图所示。

大家看下上图,是不是发现两个存活对象被挤压在一起了?然后红圈地方是不是多出来一大块连续可用的内存空间?不再是之前的一小片内存碎片了吧?


频繁Full GC导致的大量内存碎片

但是大家现在要明白一点,上述两个参数“-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=5”是设置的5次Full GC之后才会进行一次压缩操作,解决内存碎片的问题,空出来大片的连续可用内存空间。

所以这就直接导致在这5次Full GC的过程中,每一次Full GC之后都会产生大量的内存碎片。

大量的内存碎片会导致很多问题,其中一个问题,就是提高Full GC的频率。

为什么呢?因为大家之前应该还记得我们讲过,触发老年代GC的一个非常重要的条件,就是Young GC后的存活对象无法放入Survivior,就要放入老年代。

但是此时老年代假设也没足够内存放这些对象了,就必须触发Full GC了。

所以大家考虑一个场景,假设如下图所示,一次Full GC过后,老年代中有一部分内存里都是大量的内存碎片,没法放入完整的一些大对象了,只有部分内存是连续可用的内存空间。

如下图所示:

这个时候,随着大量对象快速进入老年代,会导致一旦老年代的那块连续可用内存满了,此时很多内存碎片是无法放入更多对象的,就会立马触发下一次Full GC。

比如老年代有2G的内存,其中1.5G是连续可用内存,0.5G是很多内存碎片。

本来老年代如果都是连续空内存的话,那么可能可以对象占用到将近2G才会触发Full GC。

结果现在就是对象占用到了1.5G就需要触发Full GC了,剩下0.5G是没法放任何对象的。

所以这就会导致随着一次一次Full GC导致老年代产生更多的内存碎片,连续可用内存越来越少,触发下一次FUll GC的速度就会越快。

直到几次Full GC之后,才会触发一次Compaction操作去整理内存碎片。


如何进行优化?

其实对这个案例进行优化,非常的简单,无法就是用之前讲过的jstat分析一下各个机器上的jvm的运行状况,判断出来每次Young GC后存活对象有多少,然后就是增加Survivor区的内存,避免对象快速进入老年代。

另外一个,在当时对那个系统优化之后,增加了年轻代和Survivor区的大小,但还是会慢慢的有对象进入老年代里,毕竟系统负载很高,彻底让对象不进入老年代也很难做到。所以当时调优过后每小时还是会有一次Full GC。

所以当时第二个参数的优化就是针对CMS内存碎片问题的

在降低了Full GC频率之后,务必设置如下参数“-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0”,每次Full GC后都整理一下内存碎片。

否则如果每次Full GC过后,都造成老年代里很多内存碎片,那么必然导致下一次Full GC更快到来,因为内存碎片会导致老年代可用内存变少。

也许第一次Full GC是一小时才有,第二次Full GC也许是40分钟之后,第三次Full GC可能就是20分钟之后,要是不解决CMS内存碎片问题,必然导致Full GC慢慢变得越来越频繁。


思考题

去看看你们线上系统的JVM参数,如果用的是CMS垃圾回收器的话,压缩这块是如何设置的?

考虑一下如果不是每次FUll GC后都压缩一次解决内存碎片,会对你们的系统有什么影响?


相关文章
|
1月前
|
消息中间件 监控 小程序
电竞陪玩系统架构优化设计,陪玩app如何提升系统稳定性,陪玩小程序平台的测试与监控
电竞陪玩系统架构涵盖前端(React/Vue)、后端(Spring Boot/php)、数据库(MySQL/MongoDB)、实时通信(WebSocket)及其他组件(Redis、RabbitMQ、Nginx)。通过模块化设计、微服务架构和云计算技术优化,提升系统性能与可靠性。同时,加强全面测试、实时监控及故障管理,确保系统稳定运行。
|
2月前
|
机器学习/深度学习 前端开发 算法
婚恋交友系统平台 相亲交友平台系统 婚恋交友系统APP 婚恋系统源码 婚恋交友平台开发流程 婚恋交友系统架构设计 婚恋交友系统前端/后端开发 婚恋交友系统匹配推荐算法优化
婚恋交友系统平台通过线上互动帮助单身男女找到合适伴侣,提供用户注册、个人资料填写、匹配推荐、实时聊天、社区互动等功能。开发流程包括需求分析、技术选型、系统架构设计、功能实现、测试优化和上线运维。匹配推荐算法优化是核心,通过用户行为数据分析和机器学习提高匹配准确性。
167 3
|
2月前
|
监控 架构师 Java
Java虚拟机调优的艺术:从入门到精通####
本文作为一篇深入浅出的技术指南,旨在为Java开发者揭示JVM调优的神秘面纱,通过剖析其背后的原理、分享实战经验与最佳实践,引领读者踏上从调优新手到高手的进阶之路。不同于传统的摘要概述,本文将以一场虚拟的对话形式,模拟一位经验丰富的架构师向初学者传授JVM调优的心法,激发学习兴趣,同时概括性地介绍文章将探讨的核心议题——性能监控、垃圾回收优化、内存管理及常见问题解决策略。 ####
|
2月前
|
前端开发 搜索推荐 PHP
大开眼界!uniapp秀操作,陪玩系统新功能,陪玩app源码,可实时互动随心优化!
多客游戏陪玩系统采用前端uniapp与PHP语言,实现全开源、易改造,RTC传输协议确保低延迟语音连麦,分布式部署应对高并发。功能创新包括游戏约单、多人语音聊天室、动态广场、私信聊天等,提供高端社交和个性化服务,满足各类需求,让玩家畅享游戏乐趣。
|
3月前
|
传感器 iOS开发 UED
探索iOS生态系统:从App Store优化到用户体验提升
本文旨在深入探讨iOS生态系统的多个方面,特别是如何通过App Store优化(ASO)和改进用户体验来提升应用的市场表现。不同于常规摘要仅概述文章内容的方式,我们将直接进入主题,首先介绍ASO的重要性及其对开发者的意义;接着分析当前iOS平台上用户行为的变化趋势以及这些变化如何影响应用程序的设计思路;最后提出几点实用建议帮助开发者更好地适应市场环境,增强自身竞争力。
|
3月前
|
监控 Java 编译器
Java虚拟机调优指南####
本文深入探讨了Java虚拟机(JVM)调优的精髓,从内存管理、垃圾回收到性能监控等多个维度出发,为开发者提供了一系列实用的调优策略。通过优化配置与参数调整,旨在帮助读者提升Java应用的运行效率和稳定性,确保其在高并发、大数据量场景下依然能够保持高效运作。 ####
56 1
|
3月前
|
存储 算法 Java
JVM进阶调优系列(10)敢向stop the world喊卡的G1垃圾回收器 | 有必要讲透
本文详细介绍了G1垃圾回收器的背景、核心原理及其回收过程。G1,即Garbage First,旨在通过将堆内存划分为多个Region来实现低延时的垃圾回收,每个Region可以根据其垃圾回收的价值被优先回收。文章还探讨了G1的Young GC、Mixed GC以及Full GC的具体流程,并列出了G1回收器的核心参数配置,帮助读者更好地理解和优化G1的使用。

热门文章

最新文章

  • 1
    MNN-LLM App:在手机上离线运行大模型,阿里巴巴开源基于 MNN-LLM 框架开发的手机 AI 助手应用
  • 2
    【11】flutter进行了聊天页面的开发-增加了即时通讯聊天的整体页面和组件-切换-朋友-陌生人-vip开通详细页面-即时通讯sdk准备-直播sdk准备-即时通讯有无UI集成的区别介绍-开发完整的社交APP-前端客户端开发+数据联调|以优雅草商业项目为例做开发-flutter开发-全流程-商业应用级实战开发-优雅草Alex
  • 3
    微信小程序 app.json 配置文件解析与应用
  • 4
    【Azure App Service】基于Linux创建的App Service是否可以主动升级内置的Nginx版本呢?
  • 5
    【05】flutter完成注册页面完善样式bug-增加自定义可复用组件widgets-严格规划文件和目录结构-规范入口文件-开发完整的社交APP-前端客户端开发+数据联调|以优雅草商业项目为例做开发-flutter开发-全流程-商业应用级实战开发-优雅草央千澈
  • 6
    【Azure Function】Function App出现System.IO.FileNotFoundException异常
  • 7
    原生鸿蒙版小艺APP接入DeepSeek-R1,为HarmonyOS应用开发注入新活力
  • 8
    【Azure Logic App】使用MySQL 新增行触发器遇见错误 :“Unknown column 'created_at' in 'order clause'”
  • 9
    【08】flutter完成屏幕适配-重建Android,增加GetX路由,屏幕适配,基础导航栏-多版本SDK以及gradle造成的关于fvm的使用(flutter version manage)-卓伊凡换人优雅草Alex-开发完整的社交APP-前端客户端开发+数据联调|以优雅草商业项目为例做开发-flutter开发-全流程-商业应用级实战开发-优雅草Alex
  • 10
    阿里云APP备案流程图以及备案所需材料整理,跟着教程一步步操作