Details
-
Bug
-
Status: Resolved
-
Blocker
-
Resolution: Fixed
-
6.4, 6.4.1
-
Centos 7, OpenJDK 1.8.0 update 111
Description
We've stumbled on serious performance issues after upgrading to Solr 6.4.1. Looks like the new metrics collection system in MetricsDirectoryFactory is causing a major slowdown. This happens with an index configuration that, as far as I can see, has no metrics specific configuration and uses luceneMatchVersion 5.5.0. In practice a moderate load will completely bog down the server with Solr threads constantly using up all CPU (600% on 6 core machine) capacity with a load that normally where we normally see an average load of < 50%.
I took stack traces (I'll attach them) and noticed that the threads are spending time in com.codahale.metrics.Meter.mark. I tested building Solr 6.4.1 with the metrics collection disabled in MetricsDirectoryFactory getByte and getBytes methods and was unable to reproduce the issue.
As far as I can see there are several issues:
1. Collecting metrics on every single byte read is slow.
2. Having it enabled by default is not a good idea.
3. The comment "enable coarse-grained metrics by default" at https://github.com/apache/lucene-solr/blob/branch_6x/solr/core/src/java/org/apache/solr/update/SolrIndexConfig.java#L104 implies that only coarse-grained metrics should be enabled by default, and this contradicts with collecting metrics on every single byte read.
Attachments
Attachments
Issue Links
- is broken by
-
SOLR-9854 Collect metrics for index merges and index store IO
- Resolved
- is duplicated by
-
SOLR-10172 Sorl 6 with jetty issues
- Resolved
-
SOLR-10150 Solr 6.4 up to 10x slower than 6.3
- Resolved
-
SOLR-10140 Performance degradation and CPU spike when moving to Solr 6.4.1
- Resolved
- is related to
-
SOLR-10182 Backout directory metrics collection that caused performance degradation
- Closed