1

We have an application running on OpenJDK8 that has a high allocation rate (about 80 MB/sec) over the course of the whole day.

We noticed that the overall young generation gc times directly references to the occupation of the old generation, and is getting slower and slower. How is this even possible? Also, after an enforced FullGC, the average GC time is fast again, only to slowly increase again afterwards

The workload does not change much and there is plenty of OldGen space available. Yes there is promotion to the OldGen but this is intended and can not be optimized.

Here are two graphs as proof: OldGen YoungGen

Please ignore the spikes for the OldGen, this is just a measurement error. The red lines represent the GCs.

We use these startup parameters:

-server -Xms8g -Xmx15g -XX:MaxPermSize=2048m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:NewRatio=2 -XX:SurvivorRatio=8 -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -verbose:gc

Thanks in advance.

Stefan Hueg
  • 141
  • 1
  • 5
  • This is not strange at all. Promotion to OldGen is a part of Young GC. CMS does not compact heap except during Full GC. Instead it maintains the free space in FreeList structures. The higher is OldGen occupancy - the more expensive is allocation from a FreeList during promotion. – apangin Jun 10 '19 at 21:15
  • From my understanding, this only affects the performance for OldGen allocation. As there is plenty of OldGen space available, this should not be an issue? I thought the Eden Space is compacted on every Small GC cycle? – Stefan Hueg Jun 11 '19 at 09:35
  • *"this only affects the performance for OldGen allocation"* - yes, but OldGen allocation is exatly what the promotion does. – apangin Jun 11 '19 at 10:11

0 Answers0