Hi Shawn,
Thanks for replying to my questions.
So is it correct to assume that exposing merge metrics is not known to
cause any performance degradation?
-suresh
On Wed, Jan 10, 2018 at 5:40 PM, Shawn Heisey wrote:
> On 1/10/2018 11:08 AM, S G wrote:
>
>> Last comment by Shawn on SOLR-10130 is:
On 1/10/2018 11:08 AM, S G wrote:
Last comment by Shawn on SOLR-10130 is:
Metrics was just a theory, sounds like that's not it.
It would be very interesting to know what really caused the slowdown and do
we really need the config or not.
That comment wasn't actually about SOLR-10130 itself.I c
Last comment by Shawn on SOLR-10130 is:
Metrics was just a theory, sounds like that's not it.
It would be very interesting to know what really caused the slowdown and do
we really need the config or not.
Thanks
SG
On Tue, Jan 9, 2018 at 12:00 PM, suresh pendap
wrote:
> Thanks Shalin for shar
Thanks Shalin for sharing the link. However if I follow the thread then it
seems like there was no conclusive evidence found that the performance
degradation was due to the merge or index related metrics.
If that is the case then can we just get rid of the config and publish
these metrics by defaul
The merge metrics were enabled by default in 6.4 but they were turned
off in 6.4.2 because of large performance degradations. For more
details, see https://issues.apache.org/jira/browse/SOLR-10130
On Tue, Jan 9, 2018 at 9:11 AM, S G wrote:
> Yes, this is actually confusing and the documentation (
Yes, this is actually confusing and the documentation (
https://lucene.apache.org/solr/guide/7_2/metrics-reporting.html) does not
help either:
*Index Merge Metrics* : These metrics are collected in respective
registries for each core (e.g., solr.core.collection1….), under the INDEX
category.
Basi
