理论

Question

我发现后端的Lucene段没有合并，段数增加很多。我将合并政策从LogByteSizeMergePolicy更改为TieredMergePolicy

我尝试根据solr文档更改属性，但我的细分仍然很高。

我正在使用solr 6.1.X. 索引数据存储在HDFS中。

我的solrconfig.xml索引配置：

<indexConfig>
    <writeLockTimeout>1000</writeLockTimeout>
    <commitLockTimeout>10000</commitLockTimeout>
    <maxIndexingThreads>15</maxIndexingThreads>
    <useCompoundFile>false</useCompoundFile>
    <ramBufferSizeMB>1024</ramBufferSizeMB>
    <mergePolicy class="org.apache.lucene.index.TieredMergePolicy">
          <int name="maxMergeAtOnce">10</int>
          <int name="segmentsPerTier">1</int>
    </mergePolicy>
    <mergePolicyFactory class="org.apache.solr.index.TieredMergePolicyFactory">
          <int name="maxMergeAtOnce">10</int>
          <int name="segmentsPerTier">10</int>
    </mergePolicyFactory>
    <lockType>hdfs</lockType>
    <deletionPolicy class="solr.SolrDeletionPolicy">
        <str name="maxCommitsToKeep">1</str>
        <str name="maxOptimizedCommitsToKeep">0</str>
    </deletionPolicy>
</indexConfig>

The only way we optimize is by force merging which is IO costly and also takes hours to complete.

我有一个由三个碎片组成的簇，复制因子为2。

任何人都可以在我出错的地方帮助我

Answer 1

理论

为了理解合并政策的工作原理，您可以阅读following post

简而言之，合并政策不会影响细分计数，它只决定合并哪些细分。所以主要的问题是：你有多少个细分市场？有什么问题？

另一个重要因素是索引线程的数量 - 每个线程创建它自己的线程本地段。换句话说，15个线程在磁盘上创建15个段。

请注意，使用强制合并API - 此调用根本不受IO限制。因此它可以消耗节点上的所有I / O，不会留下任何搜索内容，也可能使您的系统无响应。

实践

您可以在<infoStream>true</infoStream>中启用solrconfig.xml，这会产生类似这样的内容到Solr日志中：

   IW: commit: done writing segments file "segments_2"
   IFD: now checkpoint "_cx(6.6.1):c721" [1 segments ; isCommit = true]
   IFD: deleteCommits: now decRef commit "segments_1"
   IFD: delete StoreDirectory.deleteFile: delete file segments_1 
   TMP: findMerges: 1 segments 
   TMP: seg=_cx(6.6.1):c721 size=0.054 MB [floored]
   TMP: allowedSegmentCount=1 vs count=1 (eligible count=1) tooBigCount=0
   MS: now merge
   MS: no more merges pending; now return

所有决策均记录在案，并为每个组件提供信息说明：

IW - index writer
IFD - 删除政策
TMP - 分层合并政策
MS - 合并计划程序

solr中的段合并未发生

1 个答案:

理论

实践