слияние сегментов в solr не происходит

Я обнаружил, что сегменты 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.

Может ли кто-нибудь помочь мне, где я ошибаюсь


java solr lucene
person Chandru Shanmugasundaram    schedule 23.10.2017    source источник
comment
Для получения более подробного ответа, пожалуйста, предоставьте вывод информационного потока в свой вопрос   -  person Ivan Mamontov    schedule 23.10.2017

Ответы (1)


arrow_upward
0
arrow_downward

Теория

Чтобы понять, как работает политика слияния, вы можете прочитать следующий пост

В нескольких словах политика слияния не влияет на количество сегментов, она просто решает, какие сегменты объединять. Итак, главный вопрос: сколько у вас сегментов? В чем проблема?

Другим важным фактором является количество потоков индексации - каждый поток создает свой собственный локальный сегмент потока. Другими словами, 15 потоков создают 15 сегментов на диске.

Пожалуйста, имейте в виду, используя принудительное слияние API - этот вызов вообще не регулируется вводом-выводом. Таким образом, он может потреблять весь ввод-вывод на ваших узлах, не оставляя ничего для поиска и потенциально делая вашу систему невосприимчивой.

Упражняться

Вы можете включить <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 - автор индекса
  • IFD – политика удаления
  • TMP — многоуровневая политика слияния
  • MS - планировщик слияния
person Ivan Mamontov    schedule 23.10.2017