干货来袭！京东亿级流量电商系统JVM模型参数预估方案

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

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

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

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

对于这每秒400但会产生多大的对象呢&＃xff1f;

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

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

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

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

设置jvm参数大致如下&＃xff1a;-Xms3072M -Xmx3072M -Xss1M -XX:MetaspaceSize&＃61;512M -XX:MaxMetaspaceSize&＃61;512M


这样设置到底行不行呢&＃xff1f;有没有问题呢&＃xff1f;我们来看看运行时数据区&＃xff1a;

根据计算

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

按照这个模型来分析&＃xff0c;得到如下结果&＃xff1a;

1. 大促期间1s产生80M的对象数据。我们知道对象数据都是放在Eden园区&＃xff0c;Eden园区一共800M&＃xff0c;那么大约10s就放满了&＃xff0c;放满了就会触发Minor GC
2. 触发Minor GC的期间&＃xff0c;会Stop The World暂停业务线程。在第10s触发MinorGC的时候&＃xff0c;前9s的720M数据都已经变成垃圾了&＃xff0c;会被回收掉&＃xff0c;最后1s的80M数据由于还有对象引用&＃xff0c;只是暂停了业务线程&＃xff0c;因此不是垃圾&＃xff0c;不能被回收。会被放入S1区。
3. 在Survivor区有一个对象动态年龄判断机制。什么是对象动态年龄判断机制呢&＃xff1f;

当前放对象的Survivor区域里(其中一块区域&＃xff0c;放对象的那块s区)&＃xff0c;一批对象的总大小大于这块Survivor区域内存大小的50%(-XX:TargetSurvivorRatio可以指定)&＃xff0c;那么此时大于等于这批对象年龄最大值的对象&＃xff0c;就可以直接进入老年代了&＃xff0c;

例如&＃xff1a;Survivor区域里现在有一批对象&＃xff0c;年龄1&＃43;年龄2&＃43;年龄n的多个年龄对象总和超过了Survivor区域的50%&＃xff0c;此时就会把年龄n(含)以上的对象都放入老年代。这个规则其实是希望那些可能是长期存活的对象&＃xff0c;尽早进入老年代。

对象动态年龄判断机制一般是在minor gc之后触发的。

也就是说当在Survivor区经过几代的回收以后&＃xff0c;如果对象总和大于Survivor区域的一半&＃xff0c;则会直接放入到老年代。Survivor是100M&＃xff0c;第10s的对象是80M&＃xff0c;大于100M&＃xff0c;会直接将这个对象放入到老年代。

1. 老年代一共有2G空间&＃xff0c;2G空间执行多少次会满呢&＃xff1f;2G/80M&＃61;25次&＃xff0c;也就是发生25次&＃xff08;25秒&＃xff09;Minor GC就会触发一次Full GC。这个频率就太高了&＃xff0c;通常应该要很少触发Full GC&＃xff0c;起码也得1个小时触发一次。而触发的原因是因为垃圾对象&＃xff08;这些对象1s后都变成垃圾了&＃xff09;&＃xff0c;这样肯定是不行的。我们需要优化JVM参数。

有问题有就解决问题。问题的根本原因是老年代发生了Full GC&＃xff0c;为什么会发生Full GC呢&＃xff1f;

之所以80M对象会放到了老年代是因为每秒产生的数据 大于 Survivor区空间的一半。所以&＃xff0c;我们可以调整Survivor区大小。通常我们不会修改默认的Eden&＃xff1a;S1&＃xff1a;S2的比例&＃xff0c;所以&＃xff0c;我们可以考虑从整体扩大新生代的内存空间。假设我们扩大到2G&＃xff0c;让老年代是1G。

这时会怎么样呢&＃xff1f;

• Young区占2G&＃xff0c;Eden区有1.6G&＃xff0c; S1、S2各有200M。

这时再分析&＃xff1a;

• Eden区有1.6G&＃xff0c;每秒产生80M的对象放到Eden区&＃xff0c;大约1.6G/80&＃61;20s放满。
• 放满以后触发Minor GC, 此时前19s的对象都已经成为垃圾被回收&＃xff0c;第20s的对象被转移到S1区。
• 此时&＃xff0c;S1区有200M&＃xff0c;80
• 又过了20s&＃xff0c;进行第二次Minor GC&＃xff0c;这次Eden区又产生了1.52G的垃圾被回收&＃xff0c;之前在S1区的80M对象也已经变成垃圾被回收。新的80M对象被放入到S2区。没有进入到老年代。
• 以此类推&＃xff0c;第三次&＃xff0c;第四次&＃xff0c;垃圾对象不会再进入老年代&＃xff0c;因此也不会再发生Full GC.

由此分析&＃xff0c;大大降低了Full GC发生的频率。

最终参数设置&＃xff1a;

-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize&＃61;512M -XX:MaxMetaspaceSize&＃61;512M 为了更清晰的看到效果&＃xff0c;可以打印GC详细日志
-XX:&＃43;PrintGCDetails

4. 总结

通过上面的数据分析&＃xff0c;我们要养成一个习惯&＃xff0c;做任何事情都是要有理有据&＃xff0c;不能是拍脑袋就说出来的。一定要能够经得起验证的。

如果觉得本文对你有帮助&＃xff0c;可以转发关注支持一下