My company's webapp has been utilizing the CMS collector for almost a year now. Recently users started complaining about white screens, which we contributed to our obsessively large heap size and the fact that the RMI timer was set for every hour (and we don't use RMI) and the perm space was resizing (which caused a Full GC...that would take up to 30 secs if the heap was almost full). So I moved the RMI timer out to 24 hours and set the CMS collector to take care of Perm space. This succeeded and we no longer have an abundance of Full GCs, they are now all concurrent.
The CMS collector seems to be "too smart" for it's own good, because when peak load time hits, the CMS collector starts initiating way too early (around 5 - 7 gigs of heap utilized). Therefore only around 8G of our 14G heap is being utilized, and our CPU is around 60 - 70%. This isn't really a problem, but since we allocate 14G of space to the heap I would like to utilize this space instead of CPU. So I tried -XX:CMSInitiatingOccupancyFraction=60 and -XX:+UseCMSInitiatingOccupancyOnly to try to take control of when the CMS collector is initiating collections (I started low on the occupancy fraction and plan to increase). But, what I see in the logs makes me believe that the CMS collector is totally disregarding these new parameters. The CMS collections seem to be even more random than before. Here are my GC/Heap options and below that are snippets from our GC log: