Apache SOLR 3.5 зависает при индексации

Question

Я пытаюсь проиндексировать сайт drupal с чем-то около 1,5 миллионов узлов. В основном это простые узлы, размером около 100 тыс. Узлов (pdf-документы, обработанные с помощью tika).

Я уже несколько раз пытался выполнить индексацию, и она всегда дает сбой одним и тем же способом: SOLR падает или зависает при высокой нагрузке и использовании памяти после нескольких дней индексации (не ища максимальной пропускной способности как таковой). Сначала я переместил установку в большую коробку, с 2 CPU / 2 ГБ памяти до 8 ядер 16 ГБ памяти. Это решило проблему на некоторое время, но теперь ситуация практически идентична. Я могу проиндексировать около 500 тыс. Узлов.

Java использует намного больше памяти, чем размер кучи (в настоящее время на 8000M) (много перестановок) Нагрузка составляет около 3,0 (для маленькой и большой коробки) Solr не отвечает за индексацию. Поиск идет медленно, но возможно. Интерфейс администратора отзывчивый

Перезапуск SOLR на некоторое время решает проблему, но всегда возвращается.

При запросе размера индекса во время сбоя я замечаю, что размер каталога сильно колеблется. После запуска SOLR каталог составляет около 6,5 и работает до 13 ГБ, а затем снова падает до 6,5 ГБ. Это повторяется.

Я добавил инструкции для выхода из памяти, но это не дает мне никаких журналов.

Я использую стандартную конфигурацию SOLR для drupal 6. Я использовал различные слияния, но, похоже, это ничего не решает.

Кто-нибудь с идеями? Если вам нужна дополнительная информация, я постараюсь ответить как можно быстрее!

Это в моем журнале на данный момент: Исключение в потоке "Поток слияния Lucene # 0" org.apache.lucene.index.MergePolicy $ MergeException: java.io.FileNotFoundException: /usr/local/solr35/example/multicore/mydivp/data/index/_1bm.fnm (нет такой файл или каталог) в org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException (ConcurrentMergeScheduler.java:517) в org.apache.lucene.index.ConcurrentMergeScheduler $ MergeThread.run (ConcurrentMergeScheduler.java:482) Вызывается: java.io.FileNotFoundException: /usr/local/solr35/example/multicore/mydivp/data/index/_1bm.fnm (нет такого файла или каталога) в java.io.RandomAccessFile.open (собственный метод) at java.io.RandomAccessFile. (RandomAccessFile.java:233) в org.apache.lucene.store.MMapDirectory.openInput (MMapDirectory.java:214) в org.apache.lucene.store.FSDirectory.openInput (FSDirectory.java:345) в org.apache.lucene.index.FieldInfos. (FieldInfos.java:74) в org.apache.lucene.index.SegmentCoreReaders. (SegmentCoreReaders.java:73) в org.apache.lucene.index.SegmentReader.get (SegmentReader.java:115) в org.apache.lucene.index.IndexWriter $ ReaderPool.get (IndexWriter.java:705) в org.apache.lucene.index.IndexWriter.mergeMiddle (IndexWriter.java:4400) в org.apache.lucene.index.IndexWriter.merge (IndexWriter.java:3940) в org.apache.lucene.index.ConcurrentMergeScheduler.doMerge (ConcurrentMergeScheduler.java:388) в org.apache.lucene.index.ConcurrentMergeScheduler $ MergeThread.run (ConcurrentMergeScheduler.java:456) 2012-04-03 14: 26: 25.409: ИНФОРМАЦИЯ :: Отключение завершено

С уважением, Брэм Ронген

Обновление 2012-04-06

Это по-прежнему не работает. Проверка моего каталога данных / индекса / показывает, что Solr продолжает перестраивать / объединять. Один сегмент создается, а после этого предыдущий удаляется, и Solr запускается снова, даже когда нет новых документов. добавлено. Еще одна странность в том, что файл .fdt не увеличивается, хотя статус Solr указывает, что проиндексировано еще около 300 тыс. Документов. Самый большой файл .fdt в каталоге никогда не превышает 4,9 ГБ.

Есть мысли?

Answer 1

Ребята,

Я изменил MergePolicy на LogByteSizeMergePolicy, а MergeScheduler на ConcurrentMergeScheduler, который, похоже, решает проблему.Все еще не совсем уверен в том, что произошло, но мы вернулись к работе;)

Спасибо!

Answer 2

Этот блог может помочь понять факторы производительности (блог больше ориентирован на запросы) и политики слияния

http://www.nickveenhof.be/blog/upgrading-apache-solr-14-35-and-its-implications

Кроме того, ваши Solr и Drupal находятся на одном сервере?

Дополнительная информация. Рекомендуется установить luceneMatchVersion на последнюю версию Lucene_35, когда вы используете logbytemerge или значения по умолчанию. В новой версии lucene также должны быть исправлены утечки памяти:

<?xml version="1.0" encoding="UTF-8" ?>
<config name="my_config">
  <!-- Controls what version of Lucene various components of Solr
       adhere to.  Generally, you want to use the latest version to
       get all bug fixes and improvements. It is highly recommended
       that you fully re-index after changing this setting as it can
       affect both how text is indexed and queried.
    -->
  <luceneMatchVersion>LUCENE_35</luceneMatchVersion>
  <abortOnConfigurationError>${solr.abortOnConfigurationError:true}</abortOnConfigurationError>
  <indexDefaults>
    <useCompoundFile>false</useCompoundFile>
    <mergeFactor>10</mergeFactor>
    <!-- Tell Lucene when to flush documents to disk.
    Giving Lucene more memory for indexing means faster indexing at the cost of more RAM
    If both ramBufferSizeMB and maxBufferedDocs is set, then Lucene will flush based on whichever limit is hit first.
    -->
    <ramBufferSizeMB>32</ramBufferSizeMB>
    <maxMergeDocs>2147483647</maxMergeDocs>
    <maxFieldLength>20000</maxFieldLength>
    <writeLockTimeout>1000</writeLockTimeout>
    <commitLockTimeout>10000</commitLockTimeout>
    <!--
     Expert:
     The Merge Policy in Lucene controls how merging is handled by Lucene.  The default in 2.3 is the LogByteSizeMergePolicy, previous
     versions used LogDocMergePolicy.

     LogByteSizeMergePolicy chooses segments to merge based on their size.  The Lucene 2.2 default, LogDocMergePolicy chose when
     to merge based on number of documents

     Other implementations of MergePolicy must have a no-argument constructor
     -->
    <mergePolicy>org.apache.lucene.index.LogByteSizeMergePolicy</mergePolicy>
...