Java GC 调试手记

标签： java gc 调试 | 发表时间：2015-12-17 10:45 | 作者：san_yun
出处：http://www.iteye.com

摘要

本文记录GC调试的一次实验过程和结果。

GC知识要点回顾

问题1：为什么要调试GC参数？
在32核处理器的系统上，10%的GC时间导致75%的吞吐量损失。所以在大型系统上，调试GC是以小博大的不错选择。'small improvements in reducing such a bottleneck can produce large gains in performance.'
 
问题2：怎么样调试GC?
调试GC，有 三个主要的参数：
  • 选择合适的GC Collector
  • 整个JVM Heap堆的大小
  • Young Generation的大小(-Xmn?m or -XX:NewRatio=?)
问题3：有哪些不同的GC Collector?
Tony Printezis (JVM大牛)在 Garbage Collection in the Java HotSpot Virtual Machine有图为证，还有一篇更早的 sun开发人员介绍GC调试也是有图为证
 
neo4j总结如下
GC shortname Generation Command line parameter Comment

Copy

Young

-XX:+UseSerialGC

The Copying collector

MarkSweepCompact

Tenured

-XX:+UseSerialGC

The Mark and Sweep Compactor

ConcurrentMarkSweep

Tenured

-XX:+UseConcMarkSweepGC

The Concurrent Mark and Sweep Compactor

ParNew

Young

-XX:+UseParNewGC

The parallel Young Generation Collector — can only be used with the Concurrent mark and sweep compactor.

PS Scavenge

Young

-XX:+UseParallelGC

The parallel object scavenger

PS MarkSweep

Tenured

-XX:+UseParallelGC

The parallel mark and sweep collector
简而言之，Young和Tenured各种三种Collector，分别是
  • Serial 单线程
  • Parallel 多线程并行, GC线程和App线程取一运行，即GC要Stop the (app) world。
  • Concurrent 多线程并发，GC线程和App线程可同时运行。(注: Young generation 没有CMS，取而代之的是可和CMS(Old)一起运行的ParNew)
 
问题4：如何选择Collector?
Serial可以直接排除掉，现在最普通的服务器也有双核64位\8G内存，默认的Collector是PS Scavenge和PS MarkSweep。所以Collector在并行(Parallel)和并发(Concurrent)两者之间选择。
 
问题5：选择的标准(参数指标)是什么?如何得到这些参数值(How to measure it)?
throughput和latency。 garbage-collection-in-java-part-3从GC的耗时给出了吞吐量和响应速度的公式
Total Execution Time = Useful Time + Paused Time
throughput = Useful Time / Total Execution Time
latency = average paused time
 
如何得到Useful time 和 Paused Time?即如何得到JVM的GC时间，有以下几种方式
GC Log
打印GC log，java 启动参数中加入下面的语句(本文为tomcat应用)。GC Log 记录每次GC时间，可根据GC Log计算平均GC时间和累积GC时间。
[plain]  view plain copy
 
  1. CATALINA_OPTS="$CATALINA_OPTS -verbose:gc -Xloggc:/usr/local/tomcat/gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps"  
 
JDK自带工具，java 启动参数中加入下面的语句(本文为tomcat应用)，然后在监控端可以远程连接1090端口。在内存一项，有累积GC时间和次数。注意在以min为单位显示时，只显示整数部分，如1min20s显示为1min。
[plain]  view plain copy
 
  1. CATALINA_OPTS="$CATALINA_OPTS -Dcom.sun.management.jmxremote.port=1090 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"  
 
JVM监控工具，未同JDK一起发布，可在 JVisualvm(JDK自带)中以插件的方式使用，本文为独立使用。有累积GC时间和次数，并有曲线图直观显示。
首先在Server端启动jstatd
[plain]  view plain copy
 
  1. vi jstatd.all.policy  
  2.   
  3. grant codebase "file:${java.home}/../lib/tools.jar" {  
  4.     permission java.security.AllPermission;  
  5. };  
  6.   
  7. jstatd -J-Djava.security.policy=jstatd.all.policy  
然后在监控启动VisualGC，远程连接服务端进程id
 
问题5：应用请求的吞吐量和响应是否可以反映JVM的性能?
正是我们调优的目标。本文使用Jmeter来做压力测试，并给出吞吐量和响应 report。

测试

硬件环境
操作系统:  体系结构:  处理器的数目:  分配的虚拟内存: 
Linux 2.6.18-53.el5
amd64
2
2,680,408 Kb
物理内存总量:  可用物理内存:  交换空间总量:  可用交换空间: 
8,175,632 Kb
1,140,520 Kb
8,594,764 Kb
8,594,680 Kb
Test case
  1. 使用用 Jmeter压力测试
  2. 共6个client，每个client启动30个线程发送请求
  3. 每个请求从16种测试样例中随机挑选一个，发送到server端
  4. 测试持续10min
参数值
  1. server使用默认GC(PS Scavenge和PS MarkSweep)
  2. server使用CMS(-XX:+UseConcMarkSweepGC-XX:+UseParNewGC)
  3. server使用CMS(-XX:+UseConcMarkSweepGC -XX:+UseParNewGC)，设置Young generation的大小为200m(-Xmn200m)
  4. server使用CMS(-XX:+UseConcMarkSweepGC -XX:+UseParNewGC)，设置Young generation的大小为600m(-Xmn600m)
观察值
  1. Jmeter请求的summary report
  2. server端累积GC时间和次数
测试结果
1) CMS和Parallel比较
1.1) 吞吐量和响应
(PS Scavenge和PS MarkSweep)
(ParNew和CMS)
从Jmeter的report中可以看出, 使用CMS后吞吐量(对应总的请求数)下降18%，而最大响应时间(包括最小响应时间)有近30%的提升(变小)。这验证了Tony Printezis在Step-by-Step:Garbage Collection Tuning in the Java HotSpot™ Virtual Machine中说使用CMS应用的吞吐量会相对下降，但有更好的最差响应时间。
  • Expect longer young GC times
    • Due to slower allocations into the old gen
  • Expect better worst-case latencies
    • CMS does its work mostly-concurrently
    • Shorter worst-case pauses
  • Expect lower throughput
    • CMS does more work
在官方的JVM性能调优中给出的建议也是，如果你的应用对峰值处理有要求，而对一两秒的停顿可以接受，则使用(-XX:+UseParallelGC)；如果应用对响应有更高的要求，停顿最好小于一秒，则使用(-XX:+UseConcMarkSweepGC)。
 
1.2) GC 累积时间和次数
(PS Scavenge和PS MarkSweep)
(ParNew和CMS)
 
PS累积GC时间(visualgc)为1min25s，其中Eden 189次，共52s；old 13次，共33s。
CMS 累积GC(visualgc)为2min2s，其中Eden 2333次，共1min46s；old 55次，共16s。(Jconsole和GC log却显示没有Full GC，从 understanding cms gc logs和 jstat显示的full GC次数与CMS周期的关系中我推测visualgc与jstat显示一致，都是统计old的回收次数；而Full GC则是Young和Old一起回收，在其他类型的GC里，Old只有Full GC时才触发)。
 
可以看到PS的GC频率相对低，但每次GC时间长，每次Full在3s左右徘徊，Yong在0.3s左右；CMS则是短频快，频繁快速回收，yong在0.03s(<0.1s)左右，old<0.5s。从JMeter上，使用PS GC，Request Report会有间歇性的停顿，即server没有任何响应；CMS则相对较少，停顿不那么明显。
 
2) CMS下不同Xmn的比较
由于CMS Young太多频繁，又测试了分别调整Xmn为200m和600m之后的结果。200m是仿照 cassandra中100m * cpu #来设置Young gen的大小；600m则是与PS下的Young gen一致。
 
200m
600m
 
随着Young gen的增大(40m -> 200m -> 600m)，Young 的回收次数减少，Old的回收次数增加，总体GC累积时间下降，应用吞吐量上升，最差响应时间变慢(即便和PS比较也更差，是我的测试有问题?)。

结论

app停顿3s是不可接受的，因此倾向于使用CMS；CMS的default young gen相当小，于是设置Xmn。对于更加Prefer响应的应用，下面配置是否是黄金标配:
 
JVM_OPTS="$JVM_OPTS -XX:+UseParNewGC"
JVM_OPTS="$JVM_OPTS -XX:+UseConcMarkSweepGC"
JVM_OPTS="$JVM_OPTS -XX:+CMSParallelRemarkEnabled"
JVM_OPTS="$JVM_OPTS -XX:SurvivorRatio=8"
JVM_OPTS="$JVM_OPTS -XX:MaxTenuringThreshold=1"
JVM_OPTS="$JVM_OPTS -XX:CMSInitiatingOccupancyFraction=75"
JVM_OPTS="$JVM_OPTS -XX:+UseCMSInitiatingOccupancyOnly"


已有 0 人发表留言，猛击->> 这里<<-参与讨论


ITeye推荐



相关 [java gc 调试] 推荐：

Java GC 调试手记

- - 非技术 - ITeye博客
本文记录GC调试的一次实验过程和结果. 问题1：为什么要调试GC参数. 在32核处理器的系统上，10%的GC时间导致75%的吞吐量损失. 所以在大型系统上，调试GC是以小博大的不错选择. 问题2：怎么样调试GC?. 调试GC，有 三个主要的参数：. 选择合适的GC Collector. 整个JVM Heap堆的大小.

Java GC 调优

- - Darktea
关于 Java GC 已经有很多好的文档了, 比如这些:. 但是这里还是想再重点整理一下 Java GC 日志的格式, 可以作为实战时的备忘录.. 同时也会再整理一下各种概念. 一, JDK 6 提供的各种垃圾收集器. 先整理一下各种垃圾收集器.. 新生代收集器: Serial, ParNew, Parallel Scavenge (MaxGCPauseMillis vs.

Java GC日志查看

- - Java - 编程语言 - ITeye博客
Java中的GC有哪几种类型. 虚拟机运行在Client模式的默认值，打开此开关参数后，. 使用Serial+Serial Old收集器组合进行垃圾收集. 打开此开关参数后，使用ParNew+Serial Old收集器组合进行垃圾收集. 打开此开关参数后，使用ParNew+CMS+Serial Old收集器组合进行垃圾收集.

面向GC的Java编程

- - 并发编程网 - ifeve.com
Java程序员在编码过程中通常不需要考虑内存问题，JVM经过高度优化的GC机制大部分情况下都能够很好地处理堆(Heap)的清理问题. 以至于许多Java程序员认为，我只需要关心何时创建对象，而回收对象，就交给GC来做吧. 甚至有人说，如果在编程过程中频繁考虑内存问题，是一种退化，这些事情应该交给编译器，交给虚拟机来解决.

探秘Java虚拟机 gc的监控

- - 编程语言 - ITeye博客
1、Java虚拟机运行时的数据区. 2、常用的内存区域调节参数. -Xms：初始堆大小，默认为物理内存的1/64(<1GB)；默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制. -Xmx：最大堆大小，默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时，JVM会减少堆直到 -Xms的最小限制.

Java GC的工作原理详解

- - Java - 编程语言 - ITeye博客
JVM学习笔记之JVM内存管理和JVM垃圾回收的概念，JVM内存结构由堆、栈、本地方法栈、方法区等部分组成，另外JVM分别对新生代和旧生代采用不同的垃圾回收机制. 首先来看一下JVM内存结构，它是由堆、栈、本地方法栈、方法区等部分组成，结构图如下所示. JVM学习笔记 JVM内存管理和JVM垃圾回收.

Java垃圾回收GC概览

- - 掘金后端
    这部分的内容可以说是重中之重了，有过C/C++开发工作的人应该知道内存管理的重要性和难度. 虽然Java自己实现了内存管理，不用开发人员去操心，但其内存管理还是有不足之处，常常也会出内存泄漏和内存溢出等问题. 当我们进行这些问题排查的时候，没有掌握相关的JVM内存管理知识，那就是盲目，没有方向，掌握这部分知识在解决问题的时候才能有所依据.

成为Java GC专家（5）—Java性能调优原则

- - ImportNew
这是“ 成为Java GC专家”系列的第五篇文章. 在第一篇 深入浅出Java垃圾回收机制中，我们已经学习了不同的GC算法流程、GC的工作原理、新生代（Young Generation）和老年代（Old Generation）的概念. 你应该了解了JDK7中5种GC类型以及各种类型对应用程序的影响.

编写内存效率的java代码-面向GC

- - 非技术 - ITeye博客
Java程序员在编码过程中通常不需要考虑内存问题，JVM经过高度优化的GC机制大部分情况下都能够很好地处理堆(Heap)的清理问题. 以至于许多Java程序员认为，我只需要关心何时创建对象，而回收对象，就交给GC来做吧. 甚至有人说，如果在编程过程中频繁考虑内存问题，是一种退化，这些事情应该交给编译器，交给虚拟机来解决.

从实际案例聊聊Java应用的GC优化

- - 美团点评技术团队
当Java程序性能达不到既定目标，且其他优化手段都已经穷尽时，通常需要调整垃圾回收器来进一步提高性能，称为GC优化. 但GC算法复杂，影响GC性能的参数众多，且参数调整又依赖于应用各自的特点，这些因素很大程度上增加了GC优化的难度. 即便如此，GC调优也不是无章可循，仍然有一些通用的思考方法. 本篇会介绍这些通用的GC优化策略和相关实践案例，主要包括如下内容：.