以hbase为例:在hbase的配置文件路径下,设置了GC log输出路径/app/hbase-config/hbase-env.sh
export HBASE_OPTS="-Xmx16384m -Xms16384m -Xmn8192m -XX:PermSize=160M -XX:MaxPermSize=160M -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=3 -XX:+CMSParallelRemarkEnabled -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime -XX:PrintFLSStatistics=1 -Xloggc:/app/hbase/logs/hbase_gc.log $HBASE_OPTS"
可以查询到log的相关信息
# jstat -gccause 79751 1000 1000 //获取GC相关指标,表示每1000毫秒查询一次79751垃圾收集状况。
Usage: jstat -help|-options
jstat - [-t] [-h] [ []]
参数解释:
Options — 选项,我们一般使用 -gcutil 查看gc情况
vmid — VM的进程号,即当前运行的java进程号
interval– 间隔时间,单位为秒或者毫秒
count — 打印次数,如果缺省则打印无数次
S0 S1 E O P YGC YGCT FGC FGCT GCT LGCC GCC
0.00 8.98 11.16 69.83 12.33 156 50.788 16 280.103 330.891 unknown GCCause No GC
0.00 8.98 12.79 69.83 12.33 156 50.788 16 280.103 330.891 unknown GCCause No GC
0.00 8.98 14.94 69.83 12.33 156 50.788 16 280.103 330.891 unknown GCCause No GC
0.00 8.98 16.04 69.83 12.33 156 50.788 16 280.103 330.891 unknown GCCause No GC
0.00 8.98 17.98 69.83 12.33 156 50.788 16 280.103 330.891 unknown GCCause No GC
0.00 8.98 20.34 69.83 12.33 156 50.788 16 280.103 330.891 unknown GCCause No GC
0.00 8.98 21.83 69.83 12.33 156 50.788 16 280.103 330.891 unknown GCCause No GC
0.00 8.98 22.64 69.83 12.33 156 50.788 16 280.103 330.891 unknown GCCause No GC
E列代表
O E–>O 新生代转移到老代,O积累到80%就会触发full gc
具体意思如下:
E(表示,Eden),代表这台服务器的新生代Eden区使用了11.16的空间,
S0 S1 两个Survivor区(S0,S1表示Survivor0、Survivor1),Survivor0里面是空的,Survivor1占了8.98%
老年代(O,表示old) 和永久带(P,表示Permanent)分别使用了69.83% 和12.33%的空间。
程序运行以来共发生Minor GC(YGC ,表示young gc)156次,总耗时50.788秒;
发生Fulle GC (FGC,表示full GC )16次,full GC总耗时(FGCT,表示full gc time)为330.891秒,总的GC总耗时(GCT,表示GC Time)为330.891秒
LGCC Cause of last Garbage Collection.
GCC Cause of current Garbage Collection.
Java 6 JDK输出如下:
[hadoop@0321 logs]$ jmap -heap 29877
Attaching to process ID