Hi all
We have changed all solr configs and commit parameters that were mentioned
by Shawn,
but still - when inserting the same 300 documents from 20 threads we see no
latency
and when inserting different 300 docs from 20 threads it is very slow and no
cpu/ram/disk/network are showing high metrics
With hight entropy we see the same latency even when working with 1 shard.
Assuming that even with 1 shard, Solr is still working hard to route the
documents,
what is the component that is responsible for the document routing?
Is it the zookeeper?
And how would you verify that that's the bottle
Did you check the number of documents that end up on each shard in
these two scenarios.
My guess would be that - perhaps - low entropy key puts most of the
documents into one shard and high-entropy key causes a lot more
routing traffic with delay coming from the network communication
and/or confir
Hi
Yes it is solrCloud, we saw the same behavior with 1,2 and 4 shards. each
shard has 3 replicas.
Each bulk contains 300 docs. We get approximately 800 docs inserted in a
second.
~6000 docs are being sent in an iteration by all loading threads.
we have 20 threads, each sending bulks of 300 docs
Are you by any chance in the SolrCloud?
And to confirm, the total number of documents is the same within any
particular time period?
Regards,
Alex.
http://www.solr-start.com/ - Resources for Solr users, new and experienced
On 30 March 2017 at 10:50, moscovig wrote:
> Thanks Shawn.
>
>
Thanks Shawn.
We do specify
3
30
false
but I guess that still, the commitWithin 300 ms is a bad idea.
We will definitely try playing with the configs you suggested.
I still don't get the reason for a fast inserting when sending
On 3/30/2017 7:36 AM, moscovig wrote:
> We are using solr 6.2.1 for server and solrj 6.2.0, with no explicit commits,
> and -
>
> 3
> 30
> for autoCommit.
>
> Each request to solr contains 300 small documents with different keys., with
> a commitWithin of 300 ms.
I think the commitWith
