lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <>
Subject Re: The Impact of the Number of Collections on Indexing Performance in Solr 6.0
Date Sat, 10 Mar 2018 22:35:32 GMT

You say you've tried "many times", but you haven't provided  full
header as described in the "problems" link at the link below. You
haven't e-mailed the list owner as suggested in the "problems" link.
You haven't, in short, provided any of the information that's
necessary to actually unsubscribe you.

Please follow the instructions here: In
particular look at the "problems" link.

You must use the _exact_ same e-mail as you used to subscribe.

If the initial try doesn't work and following the suggestions at the
"problems" link doesn't work for you, let us know. But note you need
to show us the _entire_ return header to allow anyone to diagnose the


On Sat, Mar 10, 2018 at 1:03 PM, spoonerk <> wrote:
> I have manually unsubscribed many times.  But I still get emails from the
> list.  Can some admin please unsubscribe me?
> On Mar 9, 2018 9:52 PM, "苗海泉" <> wrote:
>> hello,We found a problem. In solr 6.0, the indexing speed of solr is
>> influenced by the number of solr collections. The speed is normal before
>> the limit is reached. If the limit is reached, the indexing speed will
>> decrease by 50 times.
>> In our environment, there are 49 solr nodes. If each collection has 25
>> shards, you can maintain high-speed indexing until the total number of
>> collections is about 900. To reduce the number of collections to the limit,
>> the speed will increase. Go up.
>> If each collection is 49 shards, the total number of collections can only
>> be about 700, exceeding this value will cause the index to drop
>> dramatically.
>> In the explanation, we are single copies, and multiple copies will cause
>> serious stability problems in the large solr cluster environment.
>> At first I suspect that it was due to too many thread submissions, and
>> there are still problems with this method, so I'm inclined to
>> searcherExecutor thread pool thread. This is just my guess, I want to know
>> the real reason. Can someone know if I can help?
>> Also, I noticed that the searcherExecutor thread and solr collection's
>> shards basically correspond to each other. How can I reduce the number of
>> threads or even close it? Although there are many collections in our
>> environment, there are few queries and it is not necessary to keep the
>> threads open to provide queries. This is too wasteful.
>> thank you .

View raw message