[
https://issues.apache.org/jira/browse/SOLR-13862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16957999#comment-16957999
]
Shawn Heisey commented on SOLR-13862:
-------------------------------------
We have seen changing garbage collectors require more heap memory. A few users
ran into problems when upgrading to newer Solr versions that use G1GC and had
no problems with older ones using CMS. Shenandoah promises to be a better GC
than either CMS or G1, but it is entirely possible that it will require
slightly more memory.
When seeing OutOfMemoryError, it will be important to find out which resource
was depleted. This information will be part of the exception output. It might
not be memory at all ... Java will throw that exception when other resources
are depleted as well. There are exactly two ways to deal with that exception.
You need to either increase the size of the resource, or make changes so the
program needs less of that resource. One or both of these actions may not be
possible.
My comment above was not intended to say that we aren't interested in looking
further into this problem, but because you're running a version of Java that
Oracle will be dropping in short order, it's not a high priority for us. You
have success when running on a Java version that will be well supported.
If your Solr install is using the default heap size of 512MB, which seems
likely because there is nothing in your include script to increase it, you
should know that it takes very little data in the index before that heap size
is very much too small and needs to be increased. I'm betting that if you
simply made the heap larger, Java 13 would work.
> JDK 13 stability/recovery problems
> ----------------------------------
>
> Key: SOLR-13862
> URL: https://issues.apache.org/jira/browse/SOLR-13862
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 8.2
> Reporter: Bernd Wahlen
> Priority: Major
>
> after updating my cluster (centos 7.7, solr 8.2, jdk12) to JDK13 (3 nodes, 4
> collections, 1 shard) everything was running good (with lower p95) for some
> hours. Then 2 nodes (not the leader) going to recovery state, but ~"Recovery
> failed Error opening new searcher". I tried rolling restart the cluster, but
> recovery is not working. After i switched to jdk11 recovery works again. In
> summary jdk11 or jdk12 was running stable, jdk13 not.
> This is my solr.in.sh:
> GC_TUNE="-XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC"
> SOLR_TIMEZONE="CET"
>
> GC_LOG_OPTS="-Xlog:gc*:file=/var/log/solr/solr_gc.log:time:filecount=9,filesize=20M:safepoint"
> I also tried ADDREPLICA during my attempt to reapair the cluster, which
> causes Out of Memory on JDK 13 and worked after going back to JDK 11.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
