Hmmm, may we see your solrconfig.xml file? You're right, this
is a relatively vanilla test and should be just fine. BTW, I don't
know what your latency requirements are, but extending your
auto soft commit interval to as long as you can stand isn't
a bad idea. the soft commit will invalidate a numb
Wonderful discussion, but it seems that the exact values here should only
affect the freshness of the search results and the growth of the logs. What
I have going on in a very simple, 10 node SolrCloud with quite low insert
rates (10K docs/20 minutes) absolutely kills the cloud in the first 20
min
On Fri, May 31, 2013 at 4:11 PM, Jason Hellman
wrote:
> Those are default, though autoSoftCommit is commented out by default.
>
> Keep in mind about the hard commit running every 15 seconds: it is not
> updating your searchable data (due to the openSearcher=false setting). In
> theory, your da
Those are default, though autoSoftCommit is commented out by default.
Keep in mind about the hard commit running every 15 seconds: it is not
updating your searchable data (due to the openSearcher=false setting). In
theory, your data should be searchable due to autoSoftCommit running every 1
s
15000
false
1000
I think these are close to the default values...not sure if I changed them.
These mean a hard commit every 15 seconds...right? Seems sort of reasonable
since we get a few hundred doc inserts in 15 seconds. Not sure...any advice
is very welcome.
--
View this message i
Possibly a pointer in a wrong direction, but: what's your commit
strategy? Is it possible that Solr is doing hard commits too often and
that is holding up the threads. You could switch to soft-commits with
time-based hard commits and see if that helps.
Regards,
Alex.
Personal blog: http://blog.
