JVM常见问题:
JVM内存模型
大家应该都很熟悉,合理的设置JVM内存要考虑多方面的因素,如果JVM设置不合理系统上线后会产生哪些问题呢?
Full GC
下面使用一个小小的案例来讲解如何评估JVM容量,然后合理的设置JVM内存。
使用一个 日均百万访问量服务
来简单评估下JVM内存的使用以及会面临的一些问题。
日均百万访问量是不是太抽象了,所以先计算出 平均QPS
:
平均QPS = 100w / (24h * 3600s) 复制代码
计算出 平均QPS
大约在每秒120次左右,那么这个订单订单请求每秒都会被调用大约120 次,每次调用都需要分配订单对象,一秒产生120个订单对象,30分钟后系统就会有:
订单对象 = 120 * (30m * 60s) 复制代码
216000
个订单对象,越来越多的订单对象存放在JVM中,事实上除了订单对象还会有其他的对象会存在,这个数字还要扩大10-20倍来计算。
计算出 平均QPS
那么每次请求会消耗多少内存呢?这个粗略的计算下比如:
这里我们假设是 2kb
这样一秒也就消耗 240kb内存(120 * 2kb)
看起来不大,服务压力还不明显,如果设置新生代为512m(524288kb)那大约要30分钟新生代才会被占满,然后JVM才会去执行 Minor GC
垃圾回收。
上面知道QPS为120,这样算下来好像对服务造成不了多大的压力。实际上大部分流量都会来自于白天(8个小时),再假设运营做了一个秒杀活动中午12-13点1000块秒个IPhonex,那这个时间段的流量可能要扩大10-20倍,咱们再用这个秒杀活动才计算一次:
高峰QPS = 日均QPS * 20倍 复制代码
大概高峰期QPS为2000次,那算下来一秒钟要创建2000个订单对象,将近2m的空间(2000 * 2k)再大胆一点一秒钟内存占用几十M甚至几百M,那么 Minor GC
执行的周期将非常频繁 。
每秒2000个请求,GC频繁执行,系统性能下降以往1秒就能处理完的请求,可能会达到几秒甚至几十秒才能处理完成。更可怕的是请求时间变长,以往1秒处理完后可以回收的内存,现在变成在 Minor GC
执行期间还在引用无法得到有效的回收,这就导致 Minor GC
内存回收率低下,慢慢的对象将被移到 老年代
:
上述流程反复来几次,是不是的有对象被移到老年代,请求处理完成后这些对象又会变成垃圾对象停留在老年代,老年代里的垃圾对象是不是会越来越多?
一旦老年代的垃圾对象越来越多,迟早会满,然后就会触发老年代GC,而且这个频率还很快,可能就会频繁触发老年代垃圾回收。
JVM: 这谁顶的住~~
有了一个大概容量的评估,设置JVM内存就比较简单了,下面是一些常用的JVM内存设置参数:
-Xms -Xmx -Xmn -Xss -XX:PermSize -XX:MaxPermSize
有了这些设置参数,再结合上一节给出的估算方法,就能很明白的设置这些参数的值,不用等到上线运行后再来根据访问量、并发量来慢慢调优设置了。