lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrzej Bialecki (JIRA)" <>
Subject [jira] [Commented] (SOLR-10130) Serious performance degradation in Solr 6.4.1 due to the new metrics collection
Date Thu, 27 Apr 2017 16:13:04 GMT


Andrzej Bialecki  commented on SOLR-10130:

I don't think this should make much of a difference - {{InstrumentedQueuedThreadPool}} only
exposes gauges, which basically don't add CPU overhead unless accessed, and {{InstrumentedHandler}}
collects only a few specific metrics, so the overhead should also be minimal, in the order
of microseconds / request.

A drill-down into these threads to find their hot-spots would be useful.

> Serious performance degradation in Solr 6.4.1 due to the new metrics collection
> -------------------------------------------------------------------------------
>                 Key: SOLR-10130
>                 URL:
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: metrics
>    Affects Versions: 6.4, 6.4.1
>         Environment: Centos 7, OpenJDK 1.8.0 update 111
>            Reporter: Ere Maijala
>            Assignee: Andrzej Bialecki 
>            Priority: Blocker
>              Labels: perfomance
>             Fix For: 6.4.2, master (7.0)
>         Attachments: SOLR-10130.patch, 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
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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message