JVM调优学习之旅-(7)P+CMS模拟案例优化分析思想-每秒十万的QPS社交

最新推荐文章于 2024-05-31 10:46:10 发布

yakax

最新推荐文章于 2024-05-31 10:46:10 发布

阅读量148

点赞数

分类专栏： JVM 文章标签： java jvm

本文链接：https://blog.csdn.net/yakax/article/details/108109286

版权

JVM 专栏收录该内容

8 篇文章 2 订阅

订阅专栏

模拟案例背景

很多社交APP,日活百万用户，在晚高峰时，QPS很高。
而流量最大的模块，无非就是陌生人的个人主页，类似朋友圈之类的功能。
我们都知道一般这种肯定设置的是缓存，但是问题是这些数据都是比较大的，比如一个人发布了一些感悟，等等之类的。
这些数据都是比较大的。个人信息页展示的信息也是比较完全的。这些数据我们先预估5M.

用户操作

用户在高峰期玩app的时候一般都会连续不断的点击自己感兴趣的人，然后去查看他的信息，说说之类的。
这种可能持续半小时-1小时。首先，这些服务数据的压力这边就不扯了，无非就是缓存架构。

JVM

首先这种场景，高并发下Eden区会迅速填满。频繁触发YGC，然而这时候太快了，导致很多数据还没处理完毕，这时就会把大量的数据朝着S区去，但是大概率S区放不下，会直接进入老年代。这样就会导致老年代频繁触发FGC，从而导致app来时卡顿。

优化前参数

针对上述场景，最核心的优化点，主要应该是增加机器，尽量让每台机器承载更少的并发请求，减轻压力。
同时，给年轻代的Survivor区域更大的内存空间，让每次Young GC后的存活对象务必停留在Survior中，别进入老年代

-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=5

这个JVM参数我们应该关注一下：

对象进入老年代，由于老年代没有进行碎片整理，放不下一些大对象，就会导致更快的FGC，而这两个参数就是在5次FGC后进行整理内存碎片。JVM叫这压缩，Compaction。

所以我们年轻代优化好了，还得根据FGC的次数。看老年代在高峰期FGC的次数,来进行优化这个次数。因为这个整理碎片的过程也是会STW的。

怎么优化

通过jstat分析一下各个机器上的jvm的运行状况，判断出来每次Young GC 后存活对象有多少，然后就是合理增加Survivor区的内存，避免对象快速进入老年代。

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

在降低了Full GC频率之后，务必设置如下参数“-XX:+UseCMSCompactAtFullCollection - XX:CMSFullGCsBeforeCompaction=0”，每次Full GC后都整理一下内存碎片。这个可以根据高峰期FGC次数权衡。

如果不合理修改这个参数就会导致：每次Full GC过后，都造成老年代里很多内存碎片，那么必然导致下一次Full GC更快到来，因为内存碎片会导致老年代可用内存变少。也许第一次Full GC是一小时才有，第二次Full GC也许是40分钟之后，第三次Full GC可能就是20分钟之后，要是不解决CMS内存碎片问题，必然导致Full GC慢慢变得越来越频繁

如何尽可能优化FGC

一个参数是“-XX:+CMSParallelInitialMarkEnabled”，

这个参数会在CMS垃圾回收器的“初始标记”阶段开启多线程并发执行。大家应该还记得初始标记阶段，是会进行Stop the World的，会导致系统停顿，所以这个阶段开启多线程并发之后，可以尽可能优化这个阶段的性能，减少Stop the World的时间。

另外一个参数是“-XX:+CMSScavengeBeforeRemark”，

这个参数会在CMS的重新标记阶段之前，先尽量执行一次Young GC。也就是，CMS的重新标记也是会Stop the World的，所以如果在重新标记之前，先执行一次Young GC，就会回收掉一些年轻代里没有人引用的对象。所以如果先提前回收掉一些对象，那么在CMS的重新标记阶段就可以少扫描一些对象，因为老年代对象可能会和年轻代有引用关系，gc roots寻找扫描的路径就变短了，此时就可以提升CMS的重新标记阶段的性能，减少他的耗时。