[
https://issues.apache.org/jira/browse/SOLR-13349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-13349:
----------------------------------
Description:
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
was:
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.
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
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
