On 2/7/2018 9:01 PM, mmb1234 wrote:
> I am seeing that after some time hard commits in all my solr cores stop and
> each one's searcher has an "opened at" date to be hours ago even though they
> are continuing to ingesting data successfully (index size increasing
> continuously).
>
> http://localhost:8983/solr/#/xxxxx-core/plugins?type=core&entry=searcher
> "openedAt: 2018-02-08T01:52:24.950Z"
Like Erick, I think this is really really strange. Your config looks
like it could result in some issues with opening searchers, but I
wouldn't expect it to leave you with a searcher that's hours old when
indexing is happening continuously.
> <autoCommit>
> <maxTime>${solr.autoCommit.maxTime:10000}</maxTime>
> <openSearcher>true</openSearcher>
> </autoCommit>
> <autoSoftCommit>
> <maxTime>${solr.autoSoftCommit.maxTime:-1}</maxTime>
> <maxDocs>${solr.autoSoftCommit.maxDocs:-1}</maxDocs>
> <openSearcher>false</openSearcher>
> </autoSoftCommit>
Setting openSearcher to false on autoSoftCommit makes no sense. But for
autoCommit, it SHOULD be false. For change visibility, it's better to
use soft commits than hard.
Something like this is what I recommend that you use (one minute for
autoCommit, two minutes for autoSoftCommit):
<autoCommit>
<maxTime>60000</maxTime>
<openSearcher>false</openSearcher>
</autoCommit>
<autoSoftCommit>
<maxTime>120000</maxTime>
</autoSoftCommit>
If you really want commits to happen more frequently than I have
described, then you could probably go as low as 30 seconds on
autoSoftCommit. But this will cause Solr to do more work, so I don't
recommend it unless it's actually required for your use case. I would
definitely not go any lower than 30 seconds on autoSoftCommit unless
*all* cache warming is disabled.
In your reply to Erick's message, you included *ONE* thread from a
thread dump. A different thread was included in the initial message,
but it was still only one thread. A thread dump that includes exactly
one thread isn't useful. The only thing we can say from that is that
the method is waiting on another thread to release a lock before it can
proceed ... but we can't tell WHAT it is waiting on. The entire thread
dump is required.
Due to the size of an entire thread dump, and the fact that attachments
usually don't make it to the list, you're going to need to use a paste
website or a file-sharing website to provide that information.
Thanks,
Shawn
