Garbage first UseG1GC (G1) has been present for a while as an experimental option in Java 7 and released in Java 8. Java 9 and 10 offer G1 as default collector. Of interest Java 11 is due for release in September (in a few days as I write).
When CF2018 installs it sets Parallel garbage collector. Suggest folks could do well to enable some Java logging and examine log file for performance related information like how long and when memory is in full garbage collection (java reminder full GC is a stop the world interval).
JVM arguments to add logging:
-XX:+PrintGCDetails -verbose:gc -Xloggc:cfjvmGC.log
Perform one change to CF Java by either removing UseParallelGC (G1 is default so it will apply) or replace UseParallelGC with UseG1GC (sometimes it is better to read JVM arguments and know what values you are using). Perform same load and logging as before then again take notice of time spent in garbage collection.
Findings:
Part of young collection is a pause however it is 100’s of milliseconds so other than being in the log is not felt by application load.
Concurrently happening with the load is marking of dead objects taking place helping to limit the time of clearing up non referenced objects from memory.
The memory foot print was smaller with G1.
For those that have applied G1 before it has a new parallel phase released in Java 10 speeding up performance (over that what you would notice for CF11 or CF2016 with Java 8) doing GC’s on multiple threads refer:
http://openjdk.java.net/jeps/307
As always do your own debugging and logging to know what outcomes are being achieved.
Regards, Carl.
Newbie
1 posts
Thanks for pointing out for folks the change in java 10’s g1gc, Carl.
I will be very interested to hear if it truly makes an observable difference for most over how g1 worked before, or even indeed over the parallel gc.
In my experience, gc choices and even gc “tuning” (other than heap or metaspace/permgen max sizes) are not the cause or even the best solution for most performance problems.
Rather, high heap use is usually solved by addressing whatever is using it unexpectedly (or raising the max, but not too high to cause long pauses).
And on a related but separate matter, high metaspace/permgen use is most often solved by proper sizing of the CF admin template cache size (or, again, simply raising that memory space’s max–or outright removing maxmetaspacesize in Java 8 and up, as then it is unrestricted in size).
So I was very glad to see you mention doing logging and analysis. That could help one know if they have any gc problem to begin with (in terms of unexpected pauses), and if addressing the real root cause of any gc problem helped or not.
If, then, it turned out that changing the gc algorithm alone really solved a problem, that would indeed be very interesting to hear.
I will add, for those coming across this and perhaps facing performance challenges, I understand how gc tuning has often been touted as the possible solution to such problems.
As Carl has indicated, getting gc logging is a place to start to see if that would help. But you need not stop there. You could also use jvm tools to obtain thread dumps and do heap analysis or profiling.
Or you can use tools created for CFers that facilitate doing some or all of those things, and even more. In cf8-2016 enterprise, we have the CF server monitor. In cf2018 (standard or enterprise edition) we have the new performance monitoring toolkit.
And in all cf editions and versions (old and new) we have FusionReactor and SeeFusion.
All these are much more focused on request processing than are jvm tools. They can be easier to use, as well. Indeed,FusionReactor’s Ultimate edition adds classic jvm tools like heapndumps, profilers. And step debugging all via a web interface– no IDE or jmx needed.
Carl’s conclusion is on point. Anyone debating gc changes as a solution needs to use tools to a) know their problems or b) know if any change has helped (or hurt).
I will say also that there are folks who can help with such troubleshooting and tunig. See my list of cf troubleshooting consultants (including myself) at https://www.cf411.com/cftrouble.
HTH
Does CF11 perform better with UseG1GC or useparallelgc?
Hi Jose,
Hard to say without enabling Java logging or management extensions (JMX), then read the log output or use Mission Control (JMC) to compare results. Performance could be effected if there are long pauses by full garbage collections.
I have seen some CF11 Java 8 perform better with G1 vs Parallel and I have seen some perform worse.
With CF11 Java 8 it is possible to use ConcMarkSweep and ParNew together which might perform better vs say either G1 or Parallel.
There can be other things that have impact on performance like the CFML (application code) or speed of database access. Sometimes JMC can be useful to use to know if tomcat threads are taking a long time to respond which is indicative of CFML or database slowness.
There are other vendor tools available to check on parts of CF11 performance like CFs own Server Monitoring if you have Enterprise edition.
Note: Java 9 depreciated ConcMarkSweep and ParNew. So for CF2018 with Java 10 ConcMarkSweep and ParNew are not available.
Regards, Carl
You must be logged in to post a comment.
23 Nov
10AM Pacific
Online
