一次CMS GC的调优工作

某台机器的内存比较大,之前的JVM参数是4G的堆,在压测过程中发现当QPS上来以后,Full GC会开始抬头,YoungGC的频率就不用说了,比较高。

观察GC日志和jstat -gcutil,感觉是QPS在峰值的时候对象创建比较多,也有大对象产生。于是打算加大堆的大小来延缓GC的时机,并且有一些GC参数的优化,反复调整后找到了一个适合我们的参数(没有一个best的参数,还是得按照应用的的情况去测量,最好是一遍压测一遍调整,最终找到一个best fit的参数组)。

在把堆调大的过程中比较担心下面几个问题:

1、GC的压力会不会增大?

2、一次GC的耗时会不会增加?

3、如果在GC stop-the-world的时间里,rt飙高怎么办?

这些问题最终都得到了解答,参考CMS GC的原理,结合jstat的观察,有了如下的结论。

新生代扩大3倍后,YoungGC每次会从root开始寻找存活的引用,而增大内存其实并不会导致存活对象增多(死亡对象是会增加的),因为只要你的QPS和rt是稳定的,那么同时存在的线程数也是稳定的,一个线程对应一个request,一个request中生成的对象相对是固定的,也就是说,只要QPS和rt稳定,只要内存足够,调的更大,其实正在处理的请求中的对象还是那么多,一次扫描的时间是不会明显增长的,所以往s0和s1拷贝的对象空间也是不会明显增长的,这导致YoungGC的开销和时间,其实并不会像配置的参数那样成倍增长。

而实际上,通过加大新生代的大小,YoungGC的频率明显减小,因为YoungGC是要stop-the-world的,所以应用停机的时间也会缩短。

旧生代的内存增大,可以避免QPS比较高时,内存迅速占满OldGen,触发Full GC。而对于CMS GC而言,因为上面说的新生代live对象不会明显增长,对remark阶段的耗时也是不会增长太多的,而CMS GC的sweep阶段是并发的,通过jstat可以看到Old区的占用百分比是慢慢减少的,sweep的过程对应用的rt影响不明显。

另外加入了-XX:+CMSScavengeBeforeRemark这个参数,用于在remark之前先做一次YoungGC,目的也是为了减少remark的时间,毕竟remark是要stop-the-world的。

时间: 2016-04-11

一次CMS GC的调优工作的相关文章

jvm系列(六):Java服务GC参数调优案例

本文介绍了一次生产环境的JVM GC相关参数的调优过程,通过参数的调整避免了GC卡顿对JAVA服务成功率的影响. 这段时间在整理jvm系列的文章,无意中发现本文,作者思路清晰通过步步分析最终解决问题.我个人特别喜欢这种实战类的内容,经原作者的授权同意,将文章分享于此.备注部分为本人添加,主要起到说明的作用. 原文出处:https://segmentfault.com/a/1190000005174819 背景以及遇到的问题 我们的Java HTTP服务属于OLTP类型,对成功率和响应时间的要求比

Java性能调优工程的几点建议

2016年8月,由极客邦.InfoQ和听云联合主办 APMCon 2016 中国应用性能管理大会上,Java性能调优专家Monica Beckwith进行了<Java性能调优必读守则>(原题目:Java Performance Engineer's Survival Guide)的演讲.演讲中,Monica给出关于Java调优最佳实践的个人建议:怎样设定需要调优的性能要求.需要对哪些指标进行分析.目标设定后又怎样具体地开展调优. Monica Beckwith专注于企业级应用中Java虚拟机和

Java CMS GC 361s引发的血案

问题现象 当前项目是基于GemFire集群开发,然而我们偶尔会遇到一个节点掉出集群的情况.在分析问题过程中,我们发现在该节点(N1)掉出去之前发生了如下事件.首先,N1最后的log时间在2015/07/23 06:25:35.544,并且直到2015/07/23 06:31:44.624(6分钟以后)在开始出现下一个log,接收到Primary Locator发出的机群中新的节点视图,处理Primary Locator给他的消息说它"Failed to respond within ack-wa

Jvm原理剖析与调优之内存结构

原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 .作者信息和本声明.否则将追究法律责任.http://dba10g.blog.51cto.com/764602/1637276 一些不得不说的概念 JVM JVM是一种用于计算设备的规范,它是一个虚构出来的计算机,是通过在实际的计算机上仿真模拟各种计算机功能来实现的.Java虚拟机包括一套字节码指令集.一组寄存器.一个栈.一个垃圾回收堆和一个存储方法域. JVM屏蔽了与具体操作系统平台相关的信息,使Java程序只需生成在Java虚拟

《大规模Java平台虚拟化与调优》——1.3 大规模Java平台的技术因素

1.3 大规模Java平台的技术因素 当设计大规模Java平台时,需要考虑很多的技术因素.例如,对于构建良好的大规模Java平台来说,需要很好地理解Java垃圾回收(garbage collection,GC)以及JVM架构.硬件和hypervisor架构.本节中,概要讨论了GC.非一致内存架构(Non-Uniform Memory Architecture,NUMA),以及在理论和实际操作中的内存限制.稍后的章节会给出更为详细的描述,但首先在整体上理解围绕大规模Java平台设计有哪些问题是非常

性能测试知多少---性能分析与调优的原理

最近一直纠结性能分析与调优如何下手,先从硬件开始,还是先从代码或数据库.从操作系统(CPU调度,内存管理,进程调度,磁盘I/O).网络.协议(HTTP, TCP/IP ),还是从应用程序代码,数据库调优,中间件配置等方面入手. 单一个中间件又分web中间件(apache .IIS),应用中间件(tomcat .weblogic .webSphere )等,虽然都是中间件,每一样拎出来往深了学都不是一朝一夕之功.但调优对于每一项的要求又不仅仅是"知道"或"会使用"这么

性能调优之我见

谈到软件产品的性能调优,我认为可以从狭义和广义两个范围来理解.从狭义的范畴来看,性能调优主要是指通过修改软件程序逻辑.结构等技术手段提升软件产品的各项性能指标,如响应时间等等:而从广义的层面来看,就不仅限于程序内部了,因为造成系统性能问题的瓶颈很可能来源于方方面面,而这种情况往往是性能调优很普遍的情况,下面就从广义的范围细分成几个角度来进行阐述. 一.软件层面 a)首先要谈到的肯定是我们自己提供的软件产品,因为它的内部设计是我们最清楚的,用户在应用时遇到性能问题首先要质疑的也是我们的产品,因此这

生产环境sql语句调优实战第六篇

生产环境中有大量的sql语句在运行,尽管有awr,ash做数据的收集统计,但是dba的调优工作大多数情况都是在问题已经发生后做排查的,有些sql语句可能执行的时间有1,2分钟左右,但是sql语句本身有潜在的性能问题,通过awr是定位不到的,ash尽管能够查到,但是我们在未知的情况下怎么知道问题发生的精确时间点,通过sql monitor能够查到一些实时的性能问题,但是还是需要按照自己的情况和要求来不间断地进行性能的监控.通过一个工具一劳永逸是不现实的. 今天想做数据迁移也有些日子了,看看生产环境

优酷土豆资深工程师:GC 调优实战

前情概要 对于线上高并发.高吞吐的Java web服务来说,长时间的GC暂停(也叫 stop- the-world)会严重影响系统吞吐.稳定性和用户体验.下文是我们的一个真实线上web系统针对GC调优过程的一个总结.这个系统在调优前,经常会反映有超秒的GC暂停问题,这种GC问题可能会导致调用方(可能是上层服务调用方.负载均衡层或客户端)阻塞.超时.甚至雪崩的情况.我们在系统资源不变的情况下,经过多轮调优,大幅降低了GC的频率和暂停时间. 前期准备 1.统计应用数据(峰值TPS.平均TPS,每秒平