[
https://issues.apache.org/jira/browse/SOLR-10130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15865945#comment-15865945
]
Henrik commented on SOLR-10130:
-------------------------------
We've also seen performance degradation with SolrCloud on 6.4.1, as I've posted
on solr-user (
http://lucene.472066.n3.nabble.com/Performance-degradation-after-upgrading-from-6-2-1-to-6-4-1-td4320226.html
):
Here are a couple of graphs. As you can see, 6.4.1 was introduced 2/10
12:00:
https://www.dropbox.com/s/qrc0wodain50azz/solr1.png?dl=0
https://www.dropbox.com/s/sdk30imm8jlomz2/solr2.png?dl=0
https://www.dropbox.com/s/rgd8bq86i3c5mga/solr2b.png?dl=0
These are two very different usage scenarios:
* Solr1 has constant updates and very volatile data (30 minutes TTL, 20
shards with no replicas, across 8 servers). Requests in the 99 percentile
went from ~400ms to 1000-1500ms. (Hystrix cutoff at 1.5s)
* Solr2 is a more traditional instance with long-lived data (updated once a
day, 24 shards with 2 replicas, across 8 servers). Requests in the 99
percentile went from ~400ms to at least 1s. (Hystrix cutoff at 1s)
> Serious performance degradation in Solr 6.4.1 due to the new metrics
> collection
> -------------------------------------------------------------------------------
>
> Key: SOLR-10130
> URL: https://issues.apache.org/jira/browse/SOLR-10130
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
> Affects Versions: 6.4.1
> Environment: Centos 7, OpenJDK 1.8.0 update 111
> Reporter: Ere Maijala
> Assignee: Andrzej Bialecki
> Priority: Blocker
> Labels: perfomance
> Fix For: master (7.0), 6.4.2
>
> Attachments: SOLR-10130.patch, solr-8983-console-f1.log
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
