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后都压缩一次解决内存碎片,会对你们的系统有什么影响?


相关文章
|
NoSQL Java Redis
秒杀抢购场景下实战JVM级别锁与分布式锁
在电商系统中,秒杀抢购活动是一种常见的营销手段。它通过设定极低的价格和有限的商品数量,吸引大量用户在特定时间点抢购,从而迅速增加销量、提升品牌曝光度和用户活跃度。然而,这种活动也对系统的性能和稳定性提出了极高的要求。特别是在秒杀开始的瞬间,系统需要处理海量的并发请求,同时确保数据的准确性和一致性。 为了解决这些问题,系统开发者们引入了锁机制。锁机制是一种用于控制对共享资源的并发访问的技术,它能够确保在同一时间只有一个进程或线程能够操作某个资源,从而避免数据不一致或冲突。在秒杀抢购场景下,锁机制显得尤为重要,它能够保证商品库存的扣减操作是原子性的,避免出现超卖或数据不一致的情况。
369 10
|
算法 网络协议 Java
【JVM】——GC垃圾回收机制(图解通俗易懂)
GC垃圾回收,标识出垃圾(计数机制、可达性分析)内存释放机制(标记清除、复制算法、标记整理、分代回收)
|
存储 监控 Java
JVM进阶调优系列(8)如何手把手,逐行教她看懂GC日志?| IT男的专属浪漫
本文介绍了如何通过JVM参数打印GC日志,并通过示例代码展示了频繁YGC和FGC的场景。文章首先讲解了常见的GC日志参数,如`-XX:+PrintGCDetails`、`-XX:+PrintGCDateStamps`等,然后通过具体的JVM参数和代码示例,模拟了不同内存分配情况下的GC行为。最后,详细解析了GC日志的内容,帮助读者理解GC的执行过程和GC处理机制。
|
Arthas 监控 Java
JVM知识体系学习七:了解JVM常用命令行参数、GC日志详解、调优三大方面(JVM规划和预调优、优化JVM环境、JVM运行出现的各种问题)、Arthas
这篇文章全面介绍了JVM的命令行参数、GC日志分析以及性能调优的各个方面,包括监控工具使用和实际案例分析。
1582 3
|
监控 架构师 Java
JVM进阶调优系列(6)一文详解JVM参数与大厂实战调优模板推荐
本文详述了JVM参数的分类及使用方法,包括标准参数、非标准参数和不稳定参数的定义及其应用场景。特别介绍了JVM调优中的关键参数,如堆内存、垃圾回收器和GC日志等配置,并提供了大厂生产环境中常用的调优模板,帮助开发者优化Java应用程序的性能。
|
存储 监控 算法
JVM调优深度剖析:内存模型、垃圾收集、工具与实战
【10月更文挑战第9天】在Java开发领域,Java虚拟机(JVM)的性能调优是构建高性能、高并发系统不可或缺的一部分。作为一名资深架构师,深入理解JVM的内存模型、垃圾收集机制、调优工具及其实现原理,对于提升系统的整体性能和稳定性至关重要。本文将深入探讨这些内容,并提供针对单机几十万并发系统的JVM调优策略和Java代码示例。
409 2
|
存储 IDE Java
实战优化公司线上系统JVM:从基础到高级
【11月更文挑战第28天】Java虚拟机(JVM)是Java语言的核心组件,它使得Java程序能够实现“一次编写,到处运行”的跨平台特性。在现代应用程序中,JVM的性能和稳定性直接影响到系统的整体表现。本文将深入探讨JVM的基础知识、基本特点、定义、发展历史、主要概念、调试工具、内存管理、垃圾回收、性能调优等方面,并提供一个实际的问题demo,使用IntelliJ IDEA工具进行调试演示。
264 0
|
9月前
|
Arthas 存储 算法
深入理解JVM,包含字节码文件,内存结构,垃圾回收,类的声明周期,类加载器
JVM全称是Java Virtual Machine-Java虚拟机JVM作用:本质上是一个运行在计算机上的程序,职责是运行Java字节码文件,编译为机器码交由计算机运行类的生命周期概述:类的生命周期描述了一个类加载,使用,卸载的整个过类的生命周期阶段:类的声明周期主要分为五个阶段:加载->连接->初始化->使用->卸载,其中连接中分为三个小阶段验证->准备->解析类加载器的定义:JVM提供类加载器给Java程序去获取类和接口字节码数据类加载器的作用:类加载器接受字节码文件。
844 55
|
4月前
|
存储 缓存 Java
我们来说一说 JVM 的内存模型
我是小假 期待与你的下一次相遇 ~
383 5
|
4月前
|
存储 缓存 算法
深入理解JVM《JVM内存区域详解 - 世界的基石》
Java代码从编译到执行需经javac编译为.class字节码,再由JVM加载运行。JVM内存分为线程私有(程序计数器、虚拟机栈、本地方法栈)和线程共享(堆、方法区)区域,其中堆是GC主战场,方法区在JDK 8+演变为使用本地内存的元空间,直接内存则用于提升NIO性能,但可能引发OOM。

热门文章

最新文章