Major 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