No, the load balancing is based on random selection of replicas and
CPU is not consulted. There are limited ways to influence the replica
selection, see
https://lucene.apache.org/solr/guide/8_4/distributed-requests.html#shards-preference-parameter
If a replica fails then the query fails and an
FWIW, I have seen Solr exhaust the IOPS burst quota on AWS causing
slow replication and high latency for search and indexing operations.
You may want to dig into cloud watch metrics and see if you are
running into a similar issue. The default IOPS quota on gp2 is very
low (100?).
Another thing to
Hi,
I have an issue with the collection reload API. The reload seems to be
hanging. It's been in the running state for many days.
Can you please suggest any documentation which explains the reload
task under the hood steps?
FYI. I am using solr 8.1
Thanks,
Moulay
I've run into the same issue with a Rails application that uses the Rsolr gem
to make calls to Solr. I will have to check if the issue is in Rsolr or in
my application, changing the %2B (+ sign) to a %20 (space char) in the
request URL fixes the issue.
I also just wanted to say hello to wunder.
Thanks for replying Shawn.Yea etc/default/solr.in.sh is updated for for 8984
and theres no modification to /etc/init.d/solrThere's no SSL related errors in
the logs on startup the entry below confuses me even more
2020-12-14 13:24:50.811 INFO (main) [ ] o.e.j.s.AbstractConnector Started
Should SubQuery be faster than FunctionQuery?
On Sat, Dec 12, 2020 at 10:24 AM Vincenzo D'Amore
wrote:
> Hi, looking at this sample it seems you have just one document for '12345',
> one for '23456' and so on so forth. If this is true, why don't just try
> with a subquery
>
>
Hi All,
As I mentioned in my previous post that reloading/refreshing of the external
file is consuming most of the time during a commit operation.
In order to nullify the impact of external files, I had deleted external
files from all the shards and issued commit through the curl command. Commit
