Solr 突然消耗整个堆

Question

我们在生产中遇到了无法调试的 Solr 行为。首先是 solr 的配置：

Solr 版本：6.5，Master 和 1 个 Slave，配置如下。

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 的图片（请点击链接查看）：

JVM Heap Memory Image

1 Document and 1 Segment addition Image

更新： 这是 SOLR 上次死亡时的 JMap 输出，我们现在已将 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 变得头晕目眩，有时它就像一种魅力。

任何关于我们可能出错的地方的指针都会很棒。

Answer 1

我之前也面临同样的问题，但后来我调查并发现了一些突然增加 SOLR 堆大小消耗的漏洞。

我曾经在我的数据库上的每个记录更新时对我的 SOLR 进行增量更新，如果文档大小更短，它可以正常工作。

但是随着文档大小的增加，SOLR 每天停止工作 5-8 次。 发现的原因是，每当您对记录进行增量更新时，SOLR 会立即更新它，但稍后 SOLR 必须再次调整所有文档索引，因此在调整过程中，如果另一个增量请求到达，它将再次启动一个新的并继续增加堆消耗，并在某一时刻停止响应。

我仍然没有找到解决这个问题的正确解决方案，但我为此实施了一个解决方法，即我停止了文档的增量更新，并使用它频繁地重新索引整个核心（每天 2-3 次）