CODEWITHSUNDEEP
javaperformancegarbage-collectionjvm
Paulo Rodrigues
Paulo Rodrigues

Reputation: 613

Tuning Garbage collector with the help of GCViewer

I'm analysing the logs from the garbage collector (using HotSpot VM) of a cluster composed by 10 nodes. I'm using parallel GC for young generation and Concurrent Mark Sweep for old.

The logs are similar in all the nodes, so the data below is from the node 1 reported by GCViewer:

Summary

Total time: ~14h

Throughput: 99,49%

Number of full gc pauses: 7

Number of gc pauses: 4722

GC performance: 36.958,8M/s

Memory

Total Heap (usage/max): 6.347,9M (79.7%) / 7.967M

Tenured Heap (usage/max): 4.457M (75%) / 5.942M

Young Heap (usage/max): 2.025M (100%) / 2.025M

Freed by full GC: 13.539,5M (0,2%)

Freed by GC: 8.367.939,6M (99,8%)

InitiatinOccFraction (avg/max): 16,1%/38,3%

Total Promotion: 12.678,919M

Pause

Full GC pauses: 7

Min/max full gc pause: ~0,5s / 8.2s

Total: 38,11s (14,4%)

GC pauses: 4722

Min/max full gc pause: ~0,00007s / 1.06s

Total: 226,41s (85,6%)

From this data I think the performance of the GC is just fine. Throughput always above 99,1 percent. We have a lot more low pauses than full GC which is something desirable too.

From my prespective, we have a system that does more or less one full GC each 2 hours, and the time spent with the GC in that time is ~260s (full GC pause time + low pause time). Tenured heap does not seems to be a problem, never gets too full, although young heap is always full.

The only thing that I see that can be bad is the fact that the young heap is always full, and because of this, too many low pauses are being executed. But, increasing this heap will certainly increase the time of the GC low pauses which is not desirable. Another issue is related to the InitiatinOccFraction value (avg: 16,1%/max:38,3%). Mark Sweep initial mark might be starting too soon? What would be the advantage of increasing the minimum threshold of this property (CMSInitiatingOccupancyFraction)? Last one, it seems to me that Full GC aren't releasing too much memory in the old generation space. Freed by full GC: 13.539,5M (0,2%). If this happens, this means that I have objects that need to live long and the only solution would be to increase the heap space for the old generation?

Do you see any obvious problems with these reports?

Upvotes: 2

Views: 1260

Answers (1)

Nachiket Kate
Nachiket Kate

Reputation: 8571

I think below are the things which are not fine,

Number of full gc pauses: 7

which should be ideally 0 and minimal in practice.

Total: 226,41s (85,6%)

GC time is very high which means GC activity is happening frequently.

Tenured Heap (usage/max): 4.457M (75%) / 5.942M

Young Heap (usage/max): 2.025M (100%) / 2.025M

I think you should try increasing your young generation size a little more. In addition check GC policies also which will help you to improve performance and which suits your application. Also try using GC parameters to minimize GC pauses i.e. No. of parallel GC threads etc.

Upvotes: 3

Related Questions