我們已經被我們無法調試的生產中的Solr行爲所擊中。從這裏開始的是solr的配置:Solr消耗整個堆突然
Solr版本:6.5,具有1個從站的主站,具有如下所述的相同配置。
JVM配置:
-Xms2048m
-Xmx4096m
-XX:+ParallelRefProcEnabled
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=50
其餘全部爲默認值。
Solr的配置:
<autoCommit>
<!-- Auto hard commit in 5 minutes -->
<maxTime>{solr.autoCommit.maxTime:300000}</maxTime>
<openSearcher>false</openSearcher>
</autoCommit>
<autoSoftCommit>
<!-- Auto soft commit in 15 minutes -->
<maxTime>{solr.autoSoftCommit.maxTime:900000}</maxTime>
</autoSoftCommit>
</updateHandler>
<query>
<maxBooleanClauses>1024</maxBooleanClauses>
<filterCache class="solr.FastLRUCache" size="8192" initialSize="8192" autowarmCount="0" />
<queryResultCache class="solr.LRUCache" size="8192" initialSize="4096" autowarmCount="0" />
<documentCache class="solr.LRUCache" size="12288" initialSize="12288" autowarmCount="0" />
<cache name="perSegFilter" class="solr.search.LRUCache" size="10" initialSize="0" autowarmCount="10" regenerator="solr.NoOpRegenerator" />
<enableLazyFieldLoading>true</enableLazyFieldLoading>
<queryResultWindowSize>20</queryResultWindowSize>
<queryResultMaxDocsCached>${solr.query.max.docs:40}
</queryResultMaxDocsCached>
<useColdSearcher>false</useColdSearcher>
<maxWarmingSearchers>2</maxWarmingSearchers>
</query>
主機(AWS)配置:
RAM: 7.65GB
Cores: 4
現在,我們的Solr的工作了幾個小時完全沒有問題,有時好幾天,但有時會突然記憶跳起來,GC開始引起長時間的大停頓,沒有多少恢復。 當一個或多個細分受到嚴重提交後被添加或刪除時,我們發現這種情況經常發生。索引多少個文檔並不重要。附上的圖片顯示只有1個文件被索引,導致增加了一個片段,這一切都搞砸了,直到我們重新啓動了Solr。
下面是NewRelic的和Sematext圖像(請點擊鏈接查看):
1 Document and 1 Segment addition Image
更新:這裏是JMAP輸出時SOLR最後死於非命,我們現在已將JVM內存增加到12GB的xmx:
num #instances #bytes class name
----------------------------------------------
1: 11210921 1076248416 org.apache.lucene.codecs.lucene50.Lucene50PostingsFormat$IntBlockTermState
2: 10623486 934866768 [Lorg.apache.lucene.index.TermState;
3: 15567646 475873992 [B
4: 10623485 424939400 org.apache.lucene.search.spans.SpanTermQuery$SpanTermWeight
5: 15508972 372215328 org.apache.lucene.util.BytesRef
6: 15485834 371660016 org.apache.lucene.index.Term
7: 15477679 371464296 org.apache.lucene.search.spans.SpanTermQuery
8: 10623486 339951552 org.apache.lucene.index.TermContext
9: 1516724 150564320 [Ljava.lang.Object;
10: 724486 50948800 [C
11: 1528110 36674640 java.util.ArrayList
12: 849884 27196288 org.apache.lucene.search.spans.SpanNearQuery
13: 582008 23280320 org.apache.lucene.search.spans.SpanNearQuery$SpanNearWeight
14: 481601 23116848 org.apache.lucene.document.FieldType
15: 623073 19938336 org.apache.lucene.document.StoredField
16: 721649 17319576 java.lang.String
17: 32729 7329640 [J
18: 14643 5788376 [F
19: 137126 4388032 java.util.HashMap$Node
20: 52990 3391360 java.nio.DirectByteBufferR
21: 131072 3145728 org.apache.solr.update.VersionBucket
22: 20535 2891536 [I
23: 99073 2377752 shaded.javassist.bytecode.Utf8Info
24: 47788 1911520 java.util.TreeMap$Entry
25: 34118 1910608 org.apache.lucene.index.FieldInfo
26: 26511 1696704 org.apache.lucene.store.ByteBufferIndexInput$SingleBufferImpl
27: 17470 1677120 org.apache.lucene.codecs.lucene54.Lucene54DocValuesProducer$NumericEntry
28: 13762 1526984 java.lang.Class
29: 7323 1507408 [Ljava.util.HashMap$Node;
30: 2331 1230768 [Lshaded.javassist.bytecode.ConstInfo;
31: 18929 1211456 com.newrelic.agent.deps.org.objectweb.asm.Label
32: 25360 1014400 java.util.LinkedHashMap$Entry
33: 41388 993312 java.lang.Long
Solr上的負載並不多 - 最大值爲每分鐘2000個請求。索引負載有時可能會突然增加,但大部分時間都很低。但是正如上面提到的,有時甚至一個單一的文檔索引都可以讓solr變得眩暈,有時它就像魅力一樣。
任何指向我們可能出錯的地方都會很棒。
我在想如果改變下面的參數:** 1。 mergeScheduler 2. mergeFactor 3. ramBufferSizeMB **。也想完全刪除自動軟提交。但我不確定這是否會有所幫助,並且應該爲這些參數保留什麼值。 – user1213259