CMS-initial-mark is increasing despite the UseCMSInitiatingOccupancyOnly flag and cause concurrent mode failure

1
votes

CMS-initial-mark starts from 60% (what is expected) and constantly grow despite using: -XX:+UseCMSInitiatingOccupancyOnly and -XX:CMSInitiatingOccupancyFraction=60

Can I ask for a help why is it increasing?

Flags:

-Xms28g -Xmx28g -XX:PermSize=512m -XX:MaxPermSize=512m -Xss512k -XX:NewSize=8g -XX:MaxNewSize=8g -XX:SurvivorRatio=6 -XX:+AlwaysPreTouch -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSConcurrentMTEnabled -XX:+CMSScavengeBeforeRemark -XX:CMSWaitDuration=3600000 -XX:+ExplicitGCInvokesConcurrent -XX:CMSScheduleRemarkEdenPenetration=10 -XX:CMSMaxAbortablePrecleanTime=5000 -XX:CMSInitiatingOccupancyFraction=60 -XX:+UseCMSInitiatingOccupancyOnly

GC log:

08/25-18:00:48 [4] <48574> 145285.817: [CMS-concurrent-abortable-preclean-start]

08/25-18:00:51 [4] <48574> 145286.877: [GC (Allocation Failure) 145286.877: [ParNew (promotion failed): 6332558K->6339431K(7340032K), 1.7870705 secs]145288.664: [CMS145288.749: [CMS-concurrent-abortable-preclean: 1.138/2.932 secs] [Times: user=7.11 sys=0.04, real=2.93 secs]

08/25-18:02:14 [4] <48574> (concurrent mode failure): 20937785K->20947677K(20971520K), 82.4977633 secs] 27269752K->20947677K(28311552K), [Metaspace: 108472K->108472K(1148928K)], 84.2851262 secs] [Times: user=84.51 sys=0.01, real=84.29 secs]

oldGen history:

08/25-18:00:34 [4] <48574> 145271.408: [GC (CMS Initial Mark) [1 CMS-initial-mark: 20933339K(20971520K)] 21000667K(28311552K), 0.0057867 secs] [Times: user=0.04 sys=0.00, real=0.01 secs]

08/25-18:02:31 [4] <48574> 145388.639: [GC (CMS Initial Mark) [1 CMS-initial-mark: 20947677K(20971520K)] 21005038K(28311552K), 0.0044022 secs] [Times: user=0.03 sys=0.00, real=0.01 secs]

1
javaperformancegarbage-collectionconcurrent-mark-sweep

1 Answers

0
votes

(concurrent mode failure): 20937785K->20947677K(20971520K), 82.4977633 secs] 27269752K->20947677K(28311552K)

You have 28GiB of overall heap, 8GiB of that are new gen, which leaves 20GiB for the old generation. After a concurrent mode failure (essentially a full GC) you are left with slightly less than 20GiB on the heap. Which means the the live object set only leaves less than 1GB spare capacity in the old generation if everything gets promoted.

Either your heap is undersized - or the young generation oversized - for your workload to meet the 40% breathing room required by your IHOP, or your application is leaking.