Yes, UseNuma is only for Parallel Scavenger garbage collector and only for Solaris 9 and higher and Linux kernel 2.6.19 and glibc 2.6.1. And it performs with 64-bit better than 32-bit. So no effects for G1.
With standard applications CMS is very slightly better than G1 but when it comes to huge heaps with high fragmentation G1 is better than CMS. The documentation says, one benefit of G1 is if the application has more than 50% of the Java heap occupied with live data. So first step is to size the heap that you have about 3/4 of the heap occupied with live data and then go on comparing CMS against G1. Otherwise G1 and CMS are about same or as I said CMS might be slightly better. Also, either turn swap off or also record vmstat. This should make sure that during a garbage collection no other system activity, like moving JVM heap to swap in background, is distorting your measurements. Bernd Am 31.07.2013 05:01, schrieb Shawn Heisey: > On 7/30/2013 6:59 PM, Roman Chyla wrote: >> I have been wanting some tools for measuring performance of SOLR, similar >> to Mike McCandles' lucene benchmark. >> >> so yet another monitor was born, is described here: >> http://29min.wordpress.com/2013/07/31/measuring-solr-query-performance/ >> >> I tested it on the problem of garbage collectors (see the blogs for >> details) and so far I can't conclude whether highly customized G1 is better >> than highly customized CMS, but I think interesting details can be seen >> there. >> >> Hope this helps someone, and of course, feel free to improve the tool and >> share! > > I have a CMS config that's even more tuned than before, and it has made > things MUCH better. This new config is inspired by more info that I got > on IRC: > > http://wiki.apache.org/solr/ShawnHeisey#GC_Tuning > > The G1 customizations in your blog post don't look like they are really > G1-specific - they may be useful with CMS as well. This statement also > applies to some of the CMS parameters, so I would use those with G1 as > well for any testing. > > UseNUMA looks interesting for machines that actually are NUMA. All the > information that I can find says it is only for the throughput > (parallel) collector, so it's probably not doing anything for G1. > > The pause parameters you've got for G1 are targets only. It will *try* > to stick within those parameters, but if a collection requires more than > 50 milliseconds or has to happen more often than once a second, the > collector will ignore what you have told it. > > Thanks, > Shawn >
