Hi All,
I have been trying to reduce the response time of solr cloud(v8.10, 8
nodes). To achieve this, I have tried increasing the number of shards of
solr cloud which can help reduce data size on each shard thereby reducing
response time.
I have encountered a few questions regarding sharding st
My two cents:
1) Try to have shards small enough to fit in memory so entire index can be
cached, less disk access=more speed. So #of shards depend on the memory
available on your nodes. If you still need more read throughput add more
replicas
2) At some point network chatter would be too much
If you're sure it is a regression, please open a JIRA ticket for it and
someone can take a look. Alternatively, please feel free to submit a PR too.
Thanks!
Ishan
On Wed, 13 Sept, 2023, 8:00 am Natarajan, Rajeswari,
wrote:
> Additional details
>
> Running Solr instance in alpine OS
> Not runn
Hello, Rajani
Just a blind guess, it may recover dropped replicas to remaining nodes.
Probably you need to request
https://solr.apache.org/guide/solr/latest/deployment-guide/cluster-node-management.html#migratereplicas
to remove replicas out of recycling node beforehand. WDYT?
On Wed, Sep 13, 2023
Hi,
There are no hard rules wrt sharding, it often comes down to measuring and
experimenting for your workload.
There are other things to consider than shard size. Why are the queries slow?
How many rows do you ask for? Do you use faceting? Grouping?
You have 25Gb of data on each of the 8 nodes
Are you modifying the correct solr.in.sh file?
How do you install solr?
Can you by any chance reproduce this in a new, tiny, fresh 9.3 cluster, to rule
out old cruft remaining from an existing install?
Jan
> 13. sep. 2023 kl. 04:29 skrev Natarajan, Rajeswari
> :
>
> Additional details
>
> Ru
On 9/12/23 18:28, rajani m wrote:
Solr 9.1.1 version, upon restarting solr on any node in the cluster, a
unique event is triggered across all the *other* nodes in the cluster that
has an impact similar to restarting solr on all the other nodes in the
cluster. There is dip in the cpu usage, all
This is all great advice.
There is no optimal number of shards. I’ve run clusters with 4 shards, we
currently have one cluster with 96 shards and one with 320 shards. The next one
we build out will probably not be sharded.
With long queries, I’ve usually seen a roughly linear speedup with shard
Yes, if your average query touches just too many documents (such as huge OR
queries) and has some processing that needs to touch each hit (scoring, result
transformation, highlighting mm), then simply splitting the elephant with
shards may help. Or if you ask for 100 facets and your facets are s
We have a sharded collection that joins with a non-sharded collection. The
non-sharded collection has a replica on every node. Does the join automatically
choose the local replica or do we need to pass in a shard preference param?
wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wun
Hi Solr Users,
Is there a way to stop sending search queries to a newly joined
node/respective shards for a few minutes?
Thanks,
Rajani
I am currently trying to run the command \gradlew build and it says this:
" Task :solr:documentation:changesToHtml FAILED". I have java version 17, I
am wondering if anyone has had this issue before and how they have fixed
it. Thankyou
Hi,
Thank you for looking into this one.
I tailed the logs and figured it is the new node that is the culprit, it is
failing search queries upon startup for sometime. The errors as seen below.
This query failure on that node and shard(s) is causing overall aggregated
search query to take about
Hello Walter.
I think the former has a place - join picks local replica or fail. I don't
think join query (unless crossCollection) bothers about shard preference.
On Wed, Sep 13, 2023 at 7:21 PM Walter Underwood
wrote:
> We have a sharded collection that joins with a non-sharded collection. The
As I said, these are two different collections. —wunder
> On Sep 13, 2023, at 12:08 PM, Mikhail Khludnev wrote:
>
> Hello Walter.
> I think the former has a place - join picks local replica or fail. I don't
> think join query (unless crossCollection) bothers about shard preference.
>
> On Wed,
Nope , turned out to be adding the setting in wrong condition loop in
solr.in.sh
Thanks,
Rajeswari
On 9/13/23, 5:34 AM, "Ishan Chattopadhyaya" mailto:ichattopadhy...@gmail.com>> wrote:
If you're sure it is a regression, please open a JIRA ticket for it and
someone can take a look. Alternativ
Yes the solr.in.sh is modified and based on the env there is different logic to
set the hostname. Solr is deployed and then modified solr.in.sh is copied .
As stated in the other email , this is user error.
Thanks,
Rajeeswari
On 9/13/23, 7:52 AM, "Jan Høydahl" mailto:jan@cominvent.com>> wro
@Walter,
how on earth are you monitoring all vital Solr Cloud Parameters for 320 shards?
Regards,
Bernd
Am 13.09.23 um 16:22 schrieb Walter Underwood:
This is all great advice.
There is no optimal number of shards. I’ve run clusters with 4 shards, we
currently have one cluster with 96 shard
18 matches
Mail list logo
