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暫停。