JVM调优:选择合适的GC collector (二)
来源:互联网 发布:开淘宝没货源怎么办 编辑:程序博客网 时间:2024/05/19 14:20
再来看看parallelGC的结果。
截取其中一段放大如下:
JVM参数如下:
java -jar -Xms10g -Xmx15g -XX:+UseParallelGC -XX:ParallelGCThreads=8 -XX:NewSize=6g -XX:MaxNewSize=6g -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:./log/gc.log Slaver.jar
XX:ParallelGCThreads是用来设置GC并行线程的数量,由于我的测试服务器是8个core,所以这里也设置成了8;
和上一篇中SerialGC的实验结果图相比,有了很大的差别:
首先是整条throughput曲线的抖动明显下降了,并且,更重要的是,整个系统的平均throughput提高了。SerialGC中的曲线在6000左右抖动,而这的实验结果图中,throughput基本上在7000以上。这说明MinorGC对系统造成的影响变小了,为了确认这一点,可以随意看一条Minor GC的log:
1020.911: [GC [PSYoungGen: 6252096K->22304K(6260544K)] 9744749K->3537437K(10454848K), 0.0831140 secs] [Times: user=0.62 sys=0.06, real=0.09 secs ]
从log中读出,一个minor GC在0.09秒内就完成了,相当于只阻塞了application 0.09秒的时间,和SerialGC相比,大概缩短为它的几分之一。正是因为minor GC的时间变短,所以系统受到的影响变小,整体性能也显著提高。
实际上,在Sun的官方文档中,ParallelGC也是被推荐为“能够最大化系统的throughput”。而且,在服务器一级的机器上,ParallelGC是被设置为默认的GC collector,也就是说,如果JVM参数什么没有,那么就是采用Parallel GC。
有一个需要注意的是,虽然real time是0.09秒,但是user time是real time的好几倍,正好说明在执行minor GC的时候是由多个thread共同完成的。
不过,和SerialGC一样,它也有一个大峡谷,和SerialGC一样,这也是Full GC发生的地方:
1239.230: [Full GC [PSYoungGen: 22048K->17780K(6268352K)] [PSOldGen: 4190181K->4194303K(9437184K)] 4212229K->4212084K(15705536K) [PSPermGen: 11049K->11049K(22400K)], 14.1572170 secs] [Times: user=14.15 sys=0.01, real=14.16 secs ]
整个Full GC持续了14.16秒,这段时间系统的throughput下降为0。这点上,ParallelGC和SerialGC相比并没有任何优势。并且,user time和real time值差不多,说明也是由单线程完成的Full GC的工作。
最后需要指出的是,采用ParallelGC的实验发生Full GC的时间和Seral GC相比要更早一些。这主要是因为平均的throughput要比前者更好,所以插入数据的速度更快,所以tenured generation更早的就被数据填满了。
ParallelOldGC
JVM参数如下:
java -jar -Xms10g -Xmx15g -XX:+UseParallelOldGC -XX:ParallelGCThreads=8 -XX:NewSize=6g -XX:MaxNewSize=6g -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:./log/gc.log Slaver.jar
实验结果:
实验结果几乎和ParallelGC一模一样。
它的minor GC的机制和ParallelGC是一样的,所以就不多说了。
但是在Full GC的时候还是有一些差别:
1248.458: [Full GC [PSYoungGen: 22176K->0K(6268224K)] [ParOldGen: 4179368K->4166292K(9437184K)] 4201544K->4166292K(15705408K) [PSPermGen: 11047K->11032K(22400K)], 17.1588660 secs] [Times: user=124.85 sys=0.53, real=17.16 secs ]
老实说,这个结果有些出乎意料。因为按照文档,ParallelOldGC在执行FullGC的时候是多线程工作的,我原以为Full GC的时间就会相应的缩短很多。但是,至少在我的实验中,两者的Full GC的时间差不多(14.16 vs 17.16)。唯一让我确定ParallelOldGC确实是采用多线程工作的是,user time相比real time委实大了好几倍。但是貌似多线程的Full GC在我这里没有起到作用。
(CMS collector比较麻烦,下篇再说)
补充一下,前一篇中各种collector的示意图摘自:
http://www.devx.com/java/Article/21977/0/page/3
- JVM调优:选择合适的GC collector (二)
- JVM调优:选择合适的GC collector (二)
- JVM调优:选择合适的GC collector (二)
- JVM调优:选择合适的GC collector (二)
- JVM调优:选择合适的GC collector
- JVM调优:选择合适的GC collector
- JVM调优:选择合适的GC collector
- JVM调优:选择合适的GC collector
- JVM调优:选择合适的GC collector (一)
- JVM调优:选择合适的GC collector (三)
- JVM调优:选择合适的GC collector (三)
- JVM调优:选择合适的GC collector (一)
- JVM调优:选择合适的GC collector (三)
- JVM调优:选择合适的GC collector (一)
- JVM调优:选择合适的GC collector (三)
- JVM调优:选择合适的GC collector (一)
- JVM调优:选择合适的GC collector (三)
- JVM locate collector GC
- Laravel5.2对接Google Authenticator实现二步认证
- AVL树
- 4897: [Thu Summer Camp2016]成绩单
- java解压缩文件和不解压读取压缩文件中的文本文件内容
- |poj 3261|后缀数组|二分|Milk Patterns
- JVM调优:选择合适的GC collector (二)
- 模板方法模式1
- 18 在VS下运行C语言程序
- 顺丰和百度外卖绯闻内幕披露
- git 的使用——基本的仓库创建,文件提交,上传操作命令,远程仓库关联
- shiro权限框架
- 初涉莫比乌斯反演(附带例题)
- 什么样的PPT能助你成为一个优秀的演讲者——程序员的演讲之道
- 决策树之ID3算法