Hi Vincenzoi, Jan So I have implemented 'one doc at a time' in many use
cases where we want to keep track of each doc's update history in high
velocity settings. Batching is great but not if you want granularity in
your ADD logs... just saying. I know you can ingest faster with batching
but I gener
Hi Jan, Matthias, thanks for your confirmation.
I didn't go deep reading the bug
https://issues.apache.org/jira/browse/SOLR-17240
Just one question, does anyone plan to work on it in the future? And, if
not, do you think it's a hard contribution? I could volunteer if it's not
too complicated.
On W
Hi
Ht is not surprising. If the cluster is told to force a commit for every single
doc, it will cause a pile-up of index segments, causing more merges, warming
etc, all while new indexing requests have to wait in line. This exhausts server
side threads and the limit of 3000 that you are seeing.
Hi Jan, thanks for your suggestion.
The solrcloud cluster where I found this configuration
(autoSoftCommit.maxDocs:1) recently went down. All nodes were affected, the
status of all collections and all replicas were down or recovering (without
success).
The only error found in all the SorCloud nodes
Rule of thumb is to commit as infrequently as possible and to batch ADD
requests instead of pushing one doc at a time. Also avoid the client
application doing explicit COMMIT calls to Solr. All this has a cost.
So if your requirement is an indexing latency of 30s, set autoCommit based on
time 3
Hi Jan, thanks for answering. This is the case, the collection has to be
updated in real time, I'm just afraid that multiple updates could slow down the
cluster.
Do you know where I could look at the source code for autoCommit and
autoSoftCommit? I would try to understand what happens in solrcloud cluster
after a softcommit is triggered.
On Sun, Oct 6, 2024 at 6:13 PM Dmitri Maziuk
wrote:
> On 10/6/24 10:22, Jan Høydahl wrote:
> > Such a low number gener
On 10/6/24 10:22, Jan Høydahl wrote:
Such a low number generally doesn't make much sense, other than perhaps very
special collection where you want to trigger commits immediately, however
maxTime:1 would normally be a better setting. Perhaps the one creating that
config intended the default to
l. 16:15 skrev Vincenzo D'Amore :
>
> Hi all,
>
> Recently, I found the following configuration in a solrcloud cluster ver.
> 8.11.2 (2 core 32GB RAM).
>
>
> ${solr.autoCommit.maxDocs:-1}
> ${solr.autoCommit.maxTime:6}
> false
&
t.maxTime:6}
> false
>
>
> *${solr.autoSoftCommit.maxDocs:1}*
> ${solr.autoSoftCommit.maxTime:-1}
>
>
> my attention was captured by autoSoftCommit.maxDocs set to 1.
> IMHO having softcommit maxdoc set to 1 is a (little?) dangerous
> configuration.
> This implies
Hi all,
Recently, I found the following configuration in a solrcloud cluster ver.
8.11.2 (2 core 32GB RAM).
${solr.autoCommit.maxDocs:-1}
${solr.autoCommit.maxTime:6}
false
*${solr.autoSoftCommit.maxDocs:1}*
${solr.autoSoftCommit.maxTime:-1}
my attention was
11 matches
Mail list logo
