亿级流量电商系统JVM模型参数二次优化

面对亿级流量的电商订单系统,本文深入探讨了JVM参数优化,包括使用ParNew和CMS垃圾收集器进行内存管理。通过需求分析、常规方案的问题以及JVM优化策略,提出了降低Full GC频率的方法,如调整Survivor区大小、设置大对象直接进入老年代、切换到ParNew+CMS垃圾收集器,并详细说明了相关参数设置,以应对高并发场景下的性能挑战。
摘要由CSDN通过智能技术生成

亿级流量电商系统JVM模型参数预估方案,在原来的基础上采用ParNew+CMS垃圾收集器

一、亿级流量分析及jvm参数设置

1. 需求分析

大促在即,拥有亿级流量的电商平台开发了一个订单系统,我们应该如何来预估其并发量?如何根据并发量来合理配置JVM参数呢?

假设,现在有一个场景,一个电商平台,比如京东,需要承担每天上亿的流量。现在开发了一个订单系统,那么这个订单系统每秒的并发量是多少呢?我们应该如何分配其内存空间呢?先来分析一下

每日亿级流量,平均一个用户点击量在20-30左右,通过这个计算出日活用户数约1亿/20=500万, 看的人多,买的人少,通常下单率不超过10%,我们按照留存率10%来计算,日均订单约50万单。这是分两种情况:

  • 一种是普通流量,非特殊节假日,通常早上、中午、晚上非工作时间有1个小时的时间集中购买。我们按照早上1小时,中午1小时,晚上1小时来计算,也就是3小时。这样平均到每秒就是50万/3/3600=46, 也就是及时并发,通常我们的服务都是一个集群,有好几台服务器承受着几十并发,应该不成问题。
  • 另一种是大促流量,比如双十一,基本流量都集中在双十一当天的投几分钟。这时每秒的并发量大概在50万/10/60=866,平均每秒并发量不到1000。这时服务集群有3台服务器,没太服务器承受的压力是400单/s。

2. 常规方案及问题暴露

对于这每秒400但会产生多大的对象呢?

我们假设订单对象的大小是1kb,实际上订单对象的大小和订单对象中的字段有关系,我们假设是1kb。每秒400单,也就是会产生400kb的订单对象。下单还涉及到其他对象,比如库存,优惠券,积分等等,我们将对象扩大20倍, 大约是(400kb*20)/秒. 可能同时还有其他操作,比如查询订单的操作,我们再讲其扩大10倍,大约是80M,也就是每秒产生约80M的对象,这些对象在1s后都会变为垃圾。

对于一台4核8G的服务器来说,通常我们不设置JVM参数,也可能会根据物理机的8G内存来设置JVM参数。如果根据JVM参数来设置参数如何设置呢?

之前说过开启逃逸分析会将对象分配到栈上,我们这里计算分析的时候暂且忽略逃逸分析分配到栈上的对象,因为这部分对象相对来说比较少。下面我们来验证上面的预估算法是否准确,会有什么样的问题呢?

物理机有8G,分给os操作系统3G,分给JVM5G,然后JVM中给堆分配3G,元数据空间分配512M,线程栈分配1M等等。这是估算,不够精细,到底分配这么多空间够不够呢,会不会浪费呢?会产生什么样的问题呢?

设置jvm参数大致如下:
  
-Xms3072M -Xmx3072M -Xss1M -XX:MetaspaceSize=512M -XX:MaxMetaspaceSize=512M 

这样设置到底行不行呢?有没有问题呢?我们来看看运行时数据区:

根据计算

  • 整个堆空间3G
    • Eden区800M
    • s1/s2各100M
  • 方法区512M
  • 一个线程1M

按照这个模型来分析ÿ

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值