JVM调优实战:G1中的to

Stella981
• 阅读 626

最近刚刚将自己的一个应用从CMS升级到G1,在一天早上,刚刚到办公室坐下,就收到手机一阵报警,去查看了监控,发现机器的内存出现了一个90度的涨幅,如下图所示:

JVM调优实战:G1中的to

在查看GC日志后,发现那个时间点附近出现了“to-space exhausted”这种日志(关于G1的日志学习,参见我之前的文章:【译】深入理解G1的GC日志(一))

JVM调优实战:G1中的to

在这里,我比较奇怪的是为啥to-sapce exhausted会导致整个机器的内存激增。我们JVM团队同学给我的解释是:老区不够了,这个时候会把young区所有对象不管死活都转成old区对象,所以总的内存使用量会暴增。这一个知识点,我之前学习G1的时候还真没有get到(关于G1的基本知识,参见之前的文章:可能是最全面的G1学习笔记)。

不过,我有另外一个疑问:xmx和xms相同的话堆空间应该不变,一开始就分配5g,然后加上非堆内存,那么java进程起来后就会超过5g,这是没问题的;但是这里利用空闲的内存也应该是利用堆上的空间,然后整体的内存块应该已经分配出去了,应该不会出现机器内存激增的情况。JVM团队的同学给我解释道:没有,第一次读写到了才会实际从os分配出来物理内存。

针对上面的问题,我们最终确定了下面的调优建议:

  • 这次没有发生FGC,可能是由于我前面将xmx和xms调大了导致的,这次准备将xmx和xms先调回到原来的值;
  • 加上HeapDumpAfterFullGC参数,下次再发生类似情况的时候,就会触发FGC,然后自动dump堆内存,就可以针对堆内存进行分析,看看是什么对象占用了这么多内存,然后就可以针对性优化。

关于to-space exhausted的更多总结

基于上面这个问题,我又去找了一些资料,整理如下。

《Java性能权威指南》

在这本书的123页有提到,上面这种情况属于晋升失败的情况——G1收集器完成了标记阶段,开始启动混合式垃圾收集,准备要清理老年代分区,但是老年代分区在垃圾收集器释放出足够的空间之前就已经被耗尽了。这种失败通常意味着混合式垃圾收集需要更迅速得完成垃圾收集,每次新生代垃圾收集需要处理更多的老年代分区。一般来说,一系列的to-space exhausted之后会跟着一次FGC。

在我们上面的这个例子中,是old区的使用速度超过了垃圾收集器的回收速度,因此可以考虑两种调优的思路

  • 让G1更早得启动混合式垃圾收集周期,通过调小-XX:InitiatingHeapOccupancyPercent=N这个参数,默认情况下该参数是45(PS:这个参数表示的是占用整个堆内存的比例),不过,这个参数也不能调得太小,否则会导致过多的并发收集周期和混合式垃圾收集,给应用早成过多的停顿。
  • 除了考虑增加速度,还可以考虑增加每次混合式垃圾收集收集的Old分区数量,通过调整-XX:G1MixedGCCountTarget=N参数可以控制每个混合式周期中回收的Old分区数量,该参数的默认值是8;

《Java性能调优指南》

要特别关注日志片段中的"to-space exhausted"和“Evacuation Failure”两个日志,如下图所示。可以看出,Evacuation Failure消耗了684.1ms,也就是说,这次转移失败导致了将近1s的应用暂停。

JVM调优实战:G1中的to

这种情况属于转移失败,这本书给出了两点建议:

  • 和《Java性能权威指南》一样,也建议调小-XX:InitiatingHeapOccupancyPercent=N这个参数的值,因为转移失败的代价比多执行一些并发标记周期高很多
  • 建议通过调整-XX:ConcGCThreads,增加用于垃圾收集的线程个数,代价是会多一些CPU的消耗;也就是会占用Java应用的CPU时间,这一点也需要权衡一下。
  • 有时候转移失败是由于survivor分区中没有足够的空间容纳新晋升的对象,如果是这种情况,还可以考虑增加-XX:G1ReservePercent的大小,在G1中这个默认值是10%。

总结

JVM参数的调优,是一个不断推导和尝试的过程,其中最重要的数据就是GC日志和Java堆内存快照,因此:(1)在JVM参数中一定要设置HeapDumpAfterFullGC和HeapDumpOnOutOfMemoryError两个参数,可以在发送FGC和OOM的时候将当时的Java堆情况记录下来,用于事后分析;(2)GC日志要单独打印到一个日志文件中,方便分析,如果不特别设置,GC日志会打印到stdout.log中,会有其他的日志混合在中间,影响问题排查。

JVM的参数调优并不是万能的,发生OOM或者FGC的时候,业务代码中也一定有不合理的地方,需要做合理的限制和优化,不能将所有的事情都交给JVM抗。


本号专注于后端技术、JVM问题排查和优化、Java面试题、个人成长和自我管理等主题,为读者提供一线开发者的工作和成长经验,期待你能在这里有所收获。

点赞
收藏
评论区
推荐文章
blmius blmius
2年前
MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1
文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s
Jacquelyn38 Jacquelyn38
2年前
2020年前端实用代码段,为你的工作保驾护航
有空的时候,自己总结了几个代码段,在开发中也经常使用,谢谢。1、使用解构获取json数据let jsonData  id: 1,status: "OK",data: 'a', 'b';let  id, status, data: number   jsonData;console.log(id, status, number )
皕杰报表之UUID
​在我们用皕杰报表工具设计填报报表时,如何在新增行里自动增加id呢?能新增整数排序id吗?目前可以在新增行里自动增加id,但只能用uuid函数增加UUID编码,不能新增整数排序id。uuid函数说明:获取一个UUID,可以在填报表中用来创建数据ID语法:uuid()或uuid(sep)参数说明:sep布尔值,生成的uuid中是否包含分隔符'',缺省为
Stella981 Stella981
2年前
KVM调整cpu和内存
一.修改kvm虚拟机的配置1、virsheditcentos7找到“memory”和“vcpu”标签,将<namecentos7</name<uuid2220a6d1a36a4fbb8523e078b3dfe795</uuid
Easter79 Easter79
2年前
Twitter的分布式自增ID算法snowflake (Java版)
概述分布式系统中,有一些需要使用全局唯一ID的场景,这种时候为了防止ID冲突可以使用36位的UUID,但是UUID有一些缺点,首先他相对比较长,另外UUID一般是无序的。有些时候我们希望能使用一种简单一些的ID,并且希望ID能够按照时间有序生成。而twitter的snowflake解决了这种需求,最初Twitter把存储系统从MySQL迁移
Wesley13 Wesley13
2年前
mysql设置时区
mysql设置时区mysql\_query("SETtime\_zone'8:00'")ordie('时区设置失败,请联系管理员!');中国在东8区所以加8方法二:selectcount(user\_id)asdevice,CONVERT\_TZ(FROM\_UNIXTIME(reg\_time),'08:00','0
Stella981 Stella981
2年前
Django中Admin中的一些参数配置
设置在列表中显示的字段,id为django模型默认的主键list_display('id','name','sex','profession','email','qq','phone','status','create_time')设置在列表可编辑字段list_editable
Wesley13 Wesley13
2年前
MySQL部分从库上面因为大量的临时表tmp_table造成慢查询
背景描述Time:20190124T00:08:14.70572408:00User@Host:@Id:Schema:sentrymetaLast_errno:0Killed:0Query_time:0.315758Lock_
京东云开发者 京东云开发者
6个月前
Java服务总在半夜挂,背后的真相竟然是... | 京东云技术团队
最近有用户反馈测试环境Java服务总在凌晨00:00左右挂掉,用户反馈Java服务没有定时任务,也没有流量突增的情况,Jvm配置也合理,莫名其妙就挂了
Python进阶者 Python进阶者
3个月前
Excel中这日期老是出来00:00:00,怎么用Pandas把这个去除
大家好,我是皮皮。一、前言前几天在Python白银交流群【上海新年人】问了一个Pandas数据筛选的问题。问题如下:这日期老是出来00:00:00,怎么把这个去除。二、实现过程后来【论草莓如何成为冻干莓】给了一个思路和代码如下:pd.toexcel之前把这