lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <>
Subject Re: Latest advice on G1 collector?
Date Wed, 25 Jan 2017 01:46:19 GMT
On 1/23/2017 1:00 PM, Walter Underwood wrote:
> We have a workload with very long queries, and that can drive the CMS collector into
using about 20% of the CPU time. So I’m ready to try G1 on a couple of replicas and see
what happens. I’ve already upgraded to Java 8 update 121.
> I’ve read these pages:
> <>
> <>

I would really like a concrete reason as to why the Lucene wiki
recommends NEVER using G1.

If that recommendation can be backed up with demonstrable problems, then
it would make sense.  I took a look through some of the email history
sent by Jenkins, which runs automated testing of Lucene and Solr using
various configurations and Java versions.  Problems that were detected
on tests run with the G1 collector *also* happen on test runs using
other collectors.  The number of new messages from tests using G1 are a
very minor portion of the total number of new messages.  If G1 were a
root cause of big problems, I would expect the number of new failures
using G1 to be somewhere near half of the total, possibly more.

As many of you know, Solr's essential functionality comes from Lucene,
so this does matter for Solr.

I myself have never had an issue running Solr with the G1 collector.  I
haven't found any open and substantiated bugs on Lucene or Solr that
document real problems with G1 on a 64-bit JVM.  There is one bug that
happens on a 32-bit JVM ... but most users are NOT limited to 32-bit. 
For those that are limited that way, CMS is probably plenty fast because
the heap can't go beyond 2GB.

For my production and dev systems, the 4.x versions are running the G1
collector.  Most of the 5.x and later installs are using the GC tuning
that Solr contains by default, which is CMS.


View raw message