On 4/11/2022 3:15 AM, Nik Osvalds wrote:
When we were designing the system, we played around autoCommit and
softCommit settings following this guide
<https://lucidworks.com/post/understanding-transaction-logs-softcommit-and-commit-in-sorlcloud/>.
This was mainly to optimize the initial bulk load or ReIndex after a
Schema change.
We landed on a 15sec autoCommit and no soft-commit, as the only thing
that seemed to mitigate the timeout issue was to not have any Replicas
while Indexing heavily, then add them back after.
If eliminating all replicas but one so there is only the leader helps
with performance, then you could rebuild all your replicas as TLOG
instead of NRT, assuming you're running at least version 7. That way
only the leader does actual indexing.
If a 60 second autoCommit will meet your needs, then I would go to
that. During heavy indexing, it will nean Solr is doing a quarter of
the commits it is doing now, and your transaction logs should remain
small. Also, I would set openSearcher to false, and rely on other
mechanisms to make changes visible. You could go with autoSoftCommit,
having a much larger maxTime than autoCommit does, or you can have your
indexing software send an explicit commit when it finishes. You said
that you don't have NRT requirements, so opening a new searcher every 15
seconds during heavy indexing should not be required.
A memory size of 9GB sounds like you've got Solr running on virtual
machines, not bare metal. If that is correct ... an oversubscribed
hypervisor will have terrible performance on all VMs.
Thanks,
Shawn
