YGC时间飙升

半点玻璃心 2015-04-16


最近例行检查线上服务器,发现有ygc飙升的情况。正常情况下一次YGC都是几十ms,但是总是间歇性的有这么几次YGC飙升到几百ms甚至超秒级。总结了下发现每次ygc飙升的时候sys消耗都特别长。一时间找不到什么好的思路,特发出来请教下大家。另外加了PrintSafepointStatistics,用jinfo检查,启动参数检查都生效了,但是gc日志里面打印不出来相关信息

进程是hbase,所在服务器是24线程CPU,128G内存的机器,彻底关闭swap

jdk版本是hotspot 7U67

这两个问题还请大家帮忙支支招。

: 7346501K->652875K(7549760K), 0.0716480 secs] 7346501K->652875K(32715584K), 0.0722380 secs] [Times: user=1.14 sys=0.07, real=0.07 secs] 
: 7363787K->626826K(7549760K), 0.0996020 secs] 7363787K->643217K(32715584K), 0.1001230 secs] [Times: user=1.34 sys=0.04, real=0.10 secs] 
: 7337738K->782939K(7549760K), 0.0713920 secs] 7354129K->803777K(32715584K), 0.0719900 secs] [Times: user=1.11 sys=0.07, real=0.07 secs] 
: 7493851K->676023K(7549760K), 0.0752420 secs] 7514689K->714947K(32715584K), 0.0758350 secs] [Times: user=1.17 sys=0.04, real=0.08 secs] 
: 7386734K->665735K(7549760K), 0.0636230 secs] 7425658K->717535K(32715584K), 0.0641580 secs] [Times: user=1.07 sys=0.02, real=0.06 secs] 
: 7376647K->814166K(7549760K), 0.2940890 secs] 7428447K->898949K(32715584K), 0.2945970 secs] [Times: user=2.38 sys=0.90, real=0.30 secs] 
: 7525078K->603801K(7549760K), 0.1618460 secs] 7609861K->712017K(32715584K), 0.1623870 secs] [Times: user=1.99 sys=0.14, real=0.16 secs] 
: 7314651K->615140K(7549760K), 1.6447750 secs] 7422867K->824450K(32715584K), 1.6453560 secs] [Times: user=2.98 sys=1.72, real=1.65 secs] 
: 7326052K->529149K(7549760K), 1.1045210 secs] 7535362K->803906K(32715584K), 1.1051050 secs] [Times: user=1.13 sys=1.11, real=1.11 secs] 
: 7240061K->465873K(7549760K), 2.5673920 secs] 7514818K->779794K(32715584K), 2.5679250 secs] [Times: user=2.07 sys=2.66, real=2.57 secs] 
: 7176785K->553286K(7549760K), 2.2852470 secs] 7490706K->898955K(32715584K), 2.2857670 secs] [Times: user=1.66 sys=2.38, real=2.28 secs] 

 

忘记附带启动参数了

-XX:MaxDirectMemorySize=32g 
-XX:CMSInitiatingOccupancyFraction=85 
-XX:+UseConcMarkSweepGC 
-XX:+PrintGCDetails 
-XX:+PrintGCDateStamps
 -XX:PermSize=256m 
-XX:MaxPermSize=256m 
-XX:+PrintTLAB 
-XX:+PrintFlagsFinal 
-XX:+ExplicitGCInvokesConcurrent 
-XX:TargetSurvivorRatio=85 
-XX:+UseParNewGC 
-XX:+AggressiveOpts 
-Xms32g 
-Xmx32g 
-Xmn8g 
-XX:SurvivorRatio=8 
-XX:+UseCMSInitiatingOccupancyOnly 
-XX:-UseAdaptiveSizePolicy -verbose:gc -Xloggc:/data/vols/vol1/logs/region-server-gc.log 
-Xss256k 
-XX:+UseNUMA 
-XX:+PrintSafepointStatistics 
-XX:+PrintGCApplicationStoppedTime 
-XX:+PrintGCApplicationConcurrentTime 
-XX:+PrintTenuringDistribution 
-XX:+UseGCLogFileRotation 
-XX:NumberOfGCLogFiles=31 
-XX:GCLogFileSize=10M

  

yuyijq 2015-04-18
有可能是IO导致的,看看飙升的时候系统io怎样
半点玻璃心 2015-04-20
yuyijq 写道
有可能是IO导致的,看看飙升的时候系统io怎样

你的意思是,在做GC的时候,别的进程在执行大量的IO?
fh63045 2015-04-20
对象年龄分布呢?
可能是大批对象copy导致的, 可以将Y区域设置的再大些.
yizhilong28 2015-05-09
ygc 一般是new 的对象太多,而又没有释放,造成ygc,sys高估计是io高,不知道你的业务场景是啥,所以不好判断
nijiaben 2015-05-10
半点玻璃心 写道
yuyijq 写道
有可能是IO导致的,看看飙升的时候系统io怎样

你的意思是,在做GC的时候,别的进程在执行大量的IO?


这个情况非常有可能
Global site tag (gtag.js) - Google Analytics