JVM优化-CMS下高并发案例

内容

• 大流量高并发场景下估算和调优

JVM考量指标

• 系统容量(Capacity)

  根据应用运行成本，保证在有限的硬件资源下支持应用业务。
  如领导给出运维费用不超过2万 ，那么你的机器最多是2Core ,4G.
  

• 延迟(Latency)

  在应用运行时，能够在用户能忍受的响应延迟下，保证及时响应，提升用户满意度
  响应能力以最大延迟时间来判断。如一个桌面按钮对一个触发事件响应有多快；需要多长时间返回一个网页；查询一行SQL需要多久等
  

• 吞吐量(Throughput)

  1.一个时间段内完成了多少个事务操作，在一个小时内完成多少批量操作
  2.能够支持应用运行用户的高并发访问，不会出现用户访问过大时出现服务出错，无法访问问题。
  

垃圾收集器

常见垃圾收集器应用场景

• 如果整堆大小不是很大(如100MB)，选择串行收集器一般效率最高，参数：-XX:+UseSerial
• 如果应用运行在单核机器，或者虚拟机核数只有1Core，串行收集器依然合适。使用并行收集器会因为jvm执行引擎进行线程切换带来额外开销，不合算。
• 如果应用追求”吞吐量”，并且是后台应用对较长时间停顿没有特别要求。选择并行收集比较好的。参数：-XX:+UseParallelGC
• 如果应用对相应时间较高，想要较少停顿。甚至1s停顿都会导致大量请求失败，那么选择G1，ZGC，CMS都是合理的。虽然这些收集器会GC停顿通常都比较短，但它需要额外资源去处理这些工作，通常吞吐量会降低(做降低停顿的额外工作).参数：-XX：+UseConMarkSweepGC,-XX:+UseG1GC,-XX:+UseZGC等
• 创建web服务器，对响应时间要求非常高，选择性其实就在CMS，G1, ZGC上

大流量应用特点

• 本文假定使用CMS垃圾回收器。
• 对延迟非常名，吞吐量一般通过堆积器来解决
• 通过布置多个微服务集群，将业务拆分成集群单元，通过资源编排框架进行流量限制，服务降级，熔断机制等管理
• 一般都是社交、电商、游戏、支付等场景，要求短、平、快。长时间停顿会堆积海量请求，所以发生停顿很明显。需要考虑很多指标，

  1.TPS:每秒处理事务数量
  2.AVG：平均响应时间
  3.TP值，如TP90代表90%的请求响应时间小于x毫秒
  

估算

• 一种化繁为简能力，通过大致估算应用在运行的时候，产生多少对象，每个对象平均大小，得出大致需要多带内存，当前CPU核数能在每分钟可以多少服务请求等
• 如简单Feed业务来说，查询用户设计网站发送帖子，还需查询第一页留言(大概15条),共同组成每次查询后的实体

  Class Feed{
  private User use;
  Private List<Comment> commentList;
  Private String content;
  }
  

• 对上述例子进行估算，一般每个数据返回体都比较大，大概会有几KB或几十KB不等

  请求响应是6w/s，每个数据对象是20kB, 则每秒数据时120MB/s
  每天数据时20KB*60*60*24* = 18TB
  

调优

• 调优背景

  • 机器是4Core 8GB，分配给JVM 2/3的内存 10248G/32 = 5460MB,那么年轻代分到了jvm 1/3内存 5460MB/3=1820MB.根据Eden:from:to=8:1:1，得出Eden分得1460MB。根据测试只需12s就会发生一次年轻代的Minor GC。不仅如此，每隔半小时，发生一次年老代的Major GC

• 调优思路

  • 从上述jvm内存分配的，年轻代Eden=1820MB，from=to=182MB,如果稍微有流量偏移，或者流量突增，或和其他接口共用jvm，那么survivor已经装不下minor gc的存活对象，因此总有一部分容量需要年老代来补齐，导致老年代空间不足，每个半小时发生一次Major GC。总体来说是年轻代分配空间较少所致，造成年轻代、年老代频繁GC

• 问题描述图示
  

调整内存分配

• 调整策略

  因为用户请求完这些信息，很快就会成为垃圾。所以Minor GC之后，剩下的对象很少
  因此大多数对象在年轻代就销毁了。如果加大年轻代的内存分配，由于GC数据受活跃对象数影响，回收时间并不会增加太多
  故分配一般jvm内存给年轻代，设置如下：-Xmn(New为年轻代或新生代内存)
  -XX:+UseConcMarkSweepGC -Xms540 -Xmx5460 -Xmn270
  

• 调整后效果

  线上变化,调整后Minor有所改善，但是无显著提升。比较而言，Major GC间隔增加至每隔3小时，是一个非常大性能优化
  [ParNew:2292326K‐>243160K(2795520K),0.1021743secs]3264966K‐>10880154K(1215800K),0.1021417secs]
  3264966K‐>10880154K(1215800K), 0.1021417 secs]
   [Times: user=0.52 sys=0.02, real=0.2 secs]
  

再次增大年轻代

• 增大年轻代三区(Eden，survivor的from,to)

  调大年轻代(以及survivor的from,to区),让对象在年轻代的停留时间更长些，有更多buffer空间。这样世道Minor GC间隔提高到23秒
  参数如下：
  -XX:+UseConcMarkSweepGC -Xmx5460M -Xms5460 -Xmn3460M
  

其他问题

• 发布时流量突然瞬间增大

  由于每秒的请求都非常大，如果应用重启或者更新，流量瞬间打过来，JVM 还没预热完毕，这时候就会有大量的用户请求超时、失败。
  

• 优化思路

  使用负载均衡空间对新发布及其进行逐步放量预热。如第一秒请求数100/s,第二秒 200/s，第三秒 5000/s，逐渐调整至预定值。
  

• 调整图示
  

方法区/元空间默认值过小导致FullGC

• 进行上述设置后，通过放量预热，server4在6s后流量正常流通。但是奇怪的是，每次出去大约20s，就发生一次FullGC
• 通过jmap观察，年轻代和年老代空间还有较大剩余，fullgc产生原因可能是元空间默认值过小

  1.一般情况下，FullGC但是在年老代空间不足时执行。但是如果元空间（MetaSpace）无上限，每次扩容是，也会发生FullGC
  2.查看jvm元空间默认值:   java -XX:+PrintFlagsFinal 2>&1 | grep Meta
  3.默认值如下,单位大小是Byte:
  Size_t_MetaspaceSize=21807104   {pd product} {default}
  size_t MaxMetaspaceSize = 18446744073709547520      {product} {default}
  4.现在很多类库，包括Spring，都会大量生产一些动态类，20MB很容易就超了，可以调大至256MN，为了内存溢出，也要指定上限
  5.配置如下：
  -XX:+UseConcMarkSweepGC -Xmx5460M -Xms5460M -Xmn3460M -
  XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M
       ````
  

总结

• 优化指标顺序

  1.程序优化，通过优化代码，效果非常大
  2.扩容，如果金钱成本较小
  3.参数调优，在成本、吞吐量、延迟之间寻找平衡
  

• 辅助优化原则

  1.上限之前进行长时间压测，如使用Jmeter
  2.如果线上有多个节点，可以把优化在其中几个阶段生效，进行对比。等优化有真正效果后在全面推进
  3.优化过程和目标之间可能是循环的，结果和目标不匹配，要推翻重来。
  

• 高并发业务场景，对象声明周期短，需要调整年轻代保证堆得吞吐和延迟

  1.足够大的年轻代，增加系统吞吐，不会增加GC负担
  2.容量足够Survivor区，不会是对象通过分配担保进入年老代，减少对象晋升，使对象尽可能在年轻代进行Minor GC，进而减少Major GC
  3.元空间引起Full GC的过程，高并发格外突出，尤其适用大量动态类应用，通过调大初始值，解决该问题