CODEWITHSUNDEEP
javagarbage-collectionjvm
bayinamy
bayinamy

Reputation: 497

Under what circumstance will JVM stop printing gc.log?

My application's gc.log reveals the following information:

2015-05-23T03:51:10.086+0800: 648560.384: [GC 648560.384: [ParNew: 311342K->3965K(409600K), 0.0025980 secs] 390090K->82715K(1433600K), 0.0028290 secs] [Times: user=0.04 sys=0.00, real=0.00 secs] 
2015-05-23T03:51:10.506+0800: 648560.804: [GC 648560.804: [ParNew: 311165K->3784K(409600K), 0.0030820 secs] 389915K->82536K(1433600K), 0.0032760 secs] [Times: user=0.04 sys=0.00, real=0.00 secs] 
2015-05-25T15:20:54.421+0800: 862744.719: [GC 862744.719: [ParNew: 310984K->3625K(409600K), 0.0032810 secs] 389736K->82379K(1433600K), 0.0036910 secs] [Times: user=0.04 sys=0.00, real=0.00 secs] 
2015-05-25T15:20:54.549+0800: 862744.846: [GC 862744.846: [ParNew: 310825K->11547K(409600K), 0.0037930 secs] 389579K->90305K(1433600K), 0.0040420 secs] [Times: user=0.06 sys=0.00, real=0.01 secs]

As you can see, the gc.log stopped printing from 2015-05-23:03:51:10 to 2015-05-25:15:20:54.

My application is a long running server side application, and it is based on Netty. So basically it is not possible that there is no garbages to collect in these hours.

And it is not because the disk is full. There is plenty of space left.

This is my JVM arguments:

-Xmx2048m -Xms1024m -verbose:gc -Xloggc:./gc.log -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSCompactAtFullCollection -XX:MaxTenuringThreshold=10 -XX:-UseAdaptiveSizePolicy -XX:PermSize=256M -XX:MaxPermSize=512M -XX:SurvivorRatio=3  -XX:NewRatio=2 -XX:+PrintGCDateStamps  -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails

Upvotes: 1

Views: 498

Answers (1)

bayinamy
bayinamy

Reputation: 497

After a long long google, I found the problem.

It's actually a bug in linux. Please refer to this google group post

This is really a big "ouch".

Upvotes: 1

Related Questions