Why is the JVM doing so many garbage collections

Below is a jstat output from a JVM running with the following parameters

-Xmx10240m -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode 

The jstat output is with the parameters

jstat -gcutil <pid> 10s

The section is snippet over a period of 80 seconds and according to the statistics nearly 70 seconds of this is spend in GC. They are all full GCs that are being triggered.

Timestamp   S开发者_如何学Python0  S1  E       O       P       YGC     YGCT        FGC     FGCT        GCT         Diff
1040430.2   0   0   23.69   24.58   95.03   168048  22187.057   3672    4483.931    26670.988   8.175
1040440.2   0   0   0.1     24.58   95.02   168048  22187.057   3674    4495.551    26682.608   11.62
1040450.2   0   0   4.19    24.59   95.03   168048  22187.057   3677    4506.731    26693.788   11.18
1040460.2   0   0   0.01    24.45   95.02   168048  22187.057   3679    4517.391    26704.448   10.66
1040470.2   0   0   0.33    24.45   95.03   168048  22187.057   3681    4522.213    26709.27    4.822
1040480.2   0   0   0       24.43   95.02   168048  22187.057   3684    4534.816    26721.874   12.604

The PermGen space is running at almost full but I didn't think that the Sun GC mechanism will attempt to collect here and I can see a reason for collected based on the Eden or Old space.

Anyone able to give me some pointers are to what might be occuring?

Why is the JVM doing so many garbage collections.

This is most likely because the permanent generation occupancy is quite high. When using the CMS algorithm, a major collection kicks in only when the old or permanent generations occupancy exceeds a defined threshold. The default occupancy threshold for the old generation is 68% unless I am mistaken, and this can be changed using the -XX:CMSInitiatingOccupancyFraction=n flag. However, in the context of the data presented, this value appears to be immaterial as the occupancy of the old generation appears to be under 25% when the statistics were taken (this does not mean that the old generation did not fill up in the interim, but it is unlikely when the permanent generation itself is exhibiting higher occupancy).

Note that the CMS collector does not claim objects from the permanent generation by default. This would require switching on the CMSClassUnloading flag. If the behavior does not improve, then it is likely that the permanent generation is not sized correctly, and it would have to be given more memory, for it would be apparent that only few of the objects in the permanent generation are eligible for collection on every major collection cycle.