Solrcloud副本在更新后立即进入恢复模式

Question

在压力环境中，我们有一个Solr云服务器集群，其中包含10个分片，每个分片中有4个副本。 在我们的产品环境中，每个分片将有10个分片和15个副本。 我们当前的提交设置如下

    *<autoSoftCommit>
        <maxDocs>500000</maxDocs>
        <maxTime>180000</maxTime>
    </autoSoftCommit>
    <autoCommit>
        <maxDocs>2000000</maxDocs>
        <maxTime>180000</maxTime>
        <openSearcher>false</openSearcher>
    </autoCommit>*

我们索引了大约9000万份文档。 我们有两种不同的方式为文档建立索引a）完全索引。 对9000万份文档进行索引需要4个小时，并且文档进入搜索器的速度约为每秒6000次b）增量索引。 建立索引的增量更改需要一个小时。 大约有300万次更改，搜索者获得的文档速率为每秒2500个

我们有两个集合search1和search2。 当我们进行完全索引编制时，我们将在search2收集实时流量的同时在search2集合中进行索引。 完成后，我们使用别名交换集合，以便search2集合提供实时流量，而search1可用于下一次完整索引运行。 当我们进行增量索引编制时，我们在提供实时流量的search1集合中进行了编制。

我们所有的搜索器均具有12 GB的可用RAM，并具有2.93GHz @四核Intel®Xeon®CPU X5570 @我们在触发索引时已观察到以下问题。 在我们触发14个并行主机上的索引之后大约10分钟，副本进入恢复模式。 这发生在所有碎片上。 在大约20分钟内，越来越多的副本开始进入恢复模式。 大约半小时后，除领导者以外的所有副本都处于恢复模式。 我们无法限制索引编制负载，因为这会增加整体索引编制时间。 因此，要解决此问题，我们将在触发索引之前删除所有副本，然后在索引完成后将它们添加回去。

当执行增量索引时，我们观察到副本进入恢复的行为相同。 我们无法在增量索引编制过程中删除副本，因为它也正在提供实时流量。 我们试图限制索引速度，但是群集仍然可以恢复。

如果我们将群集保留为原样，则在完成索引编制后，它最终将在一段时间后恢复。 我们的测试表明，由于它正在提供实时流量，因此我们不能让这些副本进入恢复模式，因为它也会降低搜索性能。

我们尝试了如下不同的提交设置

a）没有自动软提交，没有自动硬提交和在索引编制结束时触发的提交b）没有自动软提交，是自动硬提交和索引编制结束时的提交
c）是自动软提交，不自动硬提交
d）是自动软提交，是自动硬提交
e）以上提交的不同频率设置

不幸的是，以上所有方法产生相同的行为。 副本仍可恢复。我们已将Zookeeper的超时时间从30秒增加到5分钟，问题仍然存在。 是否有任何设置可以解决此问题？

Answer 1

垃圾回收暂停可能超过clientTimeout，从而导致Zookeeper连接断开，从而导致无限的恢复周期。

频繁的优化，提交或更新以及分段合并配置的调整不当会在恢复时导致过多的开销。 此开销可能导致恢复循环。

最后，我们的组织似乎在恢复过程中可能遇到某种类型的错误。 这种情况很少见，但似乎发生在网络连接不稳定或不可靠的时候。 Zookeeper断开连接会触发恢复，并且恢复会激增内存，有时甚至会导致内存不足的情况。

更新“注意 图形查询”

我在Solr中进行图查询时遇到了短暂的停顿，这是我的组织。 图形查询是预先输入的插件/组件的一部分。 当有人提交长字符串进行预输入时，图形查询变得复杂，并导致大量的内存使用和gc暂停。