[
https://issues.apache.org/jira/browse/SOLR-13349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16801897#comment-16801897
]
Erick Erickson edited comment on SOLR-13349 at 3/26/19 4:25 PM:
----------------------------------------------------------------
I pulled the branch_6_6 code fresh and the change from 1 to 0 is there.
Hmmm, the download for 6.6.5 is dated July 2018, and this change was made to
the 6.6 code line in late November. So I'd guess it doesn't affect the
_released_ 6.6.5, but would affect 6.6.6?
[[email protected]] This was a deliberate change, do you recall what the
intent was? Any regressions we should look for?
was (Author: erickerickson):
I pulled the branch_6_6 code fresh and the change from 1 to 0 is there.
Hmmm, the download for 6.6.5 is dated July 2018, and this change was made to
the 6.6 code line in late November. So I'd guess it doesn't affect the
_released_ 6.6.5, but would affect 6.6.6?
> High CPU usage in Solr due to Java 8 bug
> ----------------------------------------
>
> Key: SOLR-13349
> URL: https://issues.apache.org/jira/browse/SOLR-13349
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 6.6, 7.7, 8.0, master (9.0)
> Reporter: Erick Erickson
> Priority: Major
>
> We've had sporadic reports of high CPU usage in Solr 7. Lukas Weiss reported
> a Java 8 bug that appears to be the root cause (I have not personally
> verified), see: [https://bugs.openjdk.java.net/browse/JDK-8129861] e-mail
> reproduced below:
> CommitTracker makes this call:
> Executors.newScheduledThreadPool(0, new
> DefaultSolrThreadFactory("commitScheduler"));
> The supposition is that calling this with 1 will fix this (untested)
> [~ichattopadhyaya] This affects 6.6 and IIUC you're spinning a new version.
> We'll need to verify and include this fix.
> [~jpountz] You're right. I first thought "naaah, it wouldn't be that far
> back" but your question made me check, thanks!
> AFAICT, this is the only place in Solr/Lucene that uses zero.
> Using Java 9+ is another work-around.
> Anyone picking this up should port to 7.7 as well.
> e-mail from the user's list (many thanks to Lukas and Adam).
> Apologies, I can’t figure out how to reply to the Solr mailing list.
> I just ran across the same high CPU usage issue. I believe it’’s caused by
> this commit which was introduced in Solr 7.7.0
>
> [https://github.com/apache/lucene-solr/commit/eb652b84edf441d8369f5188cdd5e3ae2b151434#diff-e54b251d166135a1afb7938cfe152bb5]
> There is a bug in JDK versions <=8 where using 0 threads in the
> ScheduledThreadPool causes high CPU usage:
> [https://bugs.openjdk.java.net/browse/JDK-8129861]
> Oddly, the latest version
> of solr/core/src/java/org/apache/solr/update/CommitTracker.java on
> master still uses 0 executors as the default. Presumably most everyone is
> using JDK 9 or greater which has the bug fixed, so they don’t experience
> the bug.
> Feel free to relay this back to the mailing list.
> Thanks,
> Adam Guthrie
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
