Solr потребление памяти при запуске - загрузка индексов?

Question

Мне было поручено решить проблемы OutOfMemoryError при установке Solr. Наконец-то мне удалось заставить его работать дольше нескольких минут, используя опцию AggressiveHeap JVM.

Я никогда не работал с Solr, поэтому чувствую себя немного лучше.

Это процесс, который мы предпринимаем:

1. Запустите Tomcat
2. Начать дельта-импорт

После запуска дельта-импорта потребление кучи неумолимо возрастает. Мы попытались установить Xmx на 4 гигабайта, что привело к тому, что OutOfMemoryErrors или система перестали отвечать на запросы, поэтому попробовали опцию AggressiveHeap, которая заставила JVM занять около 5,5 гигабайт оперативной памяти. Как вы можете видеть на скриншоте, на этот раз GC смог освободить память, потребление памяти стало менее быстрым, и затем справа от изображения появился еще один GC, который действительно работает, и продолжает работать так.

Что это за первоначальное распределение памяти? Индекс загружается в ОЗУ? Есть ли способ уменьшить это?

Я попытался настроить ramBufferSizeMB, maxBufferedDocs, mergeFactor, а также раскомментировал объявление StandardIndexReaderFactory, чтобы позволить мне установить termIndexDivisor в 12, но трудно понять, имели ли эти изменения какое-то значение или нет (да: требуется дополнительный анализ) .

Индекс был создан в течение нескольких неудачных сеансов индексирования - добавление параметра termIndexDivisor является более новым - неужели тот факт, что файлы индекса уже существуют, мешает этому параметру оказывать какое-либо влияние?

(Машина физическая, имеет 12 гигабайт оперативной памяти и 16 ядер. Она разделяет машину с другим крупным экземпляром Tomcat. Мы используем Oracle JDK 1.6 21)

Answer 1

Есть разные вещи. Одна вещь - mergeFactor, потому что она контролирует количество сгенерированных сегментов, и у вас будет считыватель сегментов на сегмент. Однако изменение этого параметра не приведет к немедленному изменению использования памяти. Другие параметры в основном управляют использованием ОЗУ для процессов индексации, а не использованием ОЗУ при запуске или во время поиска.

Второе - это поисковое потепление. Обычно при запуске запускаются некоторые запросы, которые нагревают поисковиков, и эти запросы кэшируются. Есть также опции, которые контролируют размер кэша. Смотрите также: http://wiki.apache.org/solr/SolrCaching

Установка termIndexDivisor в 12, очевидно, не очень хорошая вещь, если вы столкнетесь с проблемами с памятью. Насколько я знаю, в 4.x термин делитель индекса равен 256 или 128, и, по крайней мере, в 1.x он равен 32. Этот параметр определяет, сколько записей ваших терминов загружается в ОЗУ. Каждый 12-й семестр в вашем случае. У termIndexDivisor должны быть эффекты, даже если индекс уже существует.

Если ваш индекс загружен в ОЗУ, это контролируется параметром конфигурации direcotryfactory.

Если вы работаете с соединительной линией Solr, возможно, вы пропустили изменение, которое StandardDirectoryFactory разрешает при определенных обстоятельствах в MMAPDirectory, что приведет к интенсивному использованию ОЗУ (если у вас большой индекс). Это изменение произошло где-то между апрелем этого года и сейчас. Я даже не уверен, как это получилось благодаря проверке кода, но на самом деле это текущее состояние транка.

Answer 2

Я закончил копать с помощью отладчика, так как даже с рекомендациями @ fyr потребление памяти не сильно уменьшилось.

Оказалось, что и deltaQuery, и deltaImportQuery были точными копиямизапрос.Это означало, что вместо того, чтобы только возвращать PK записей, которые изменились с момента последнего импорта, запрос возвращал каждую строку, и Solr пытался сохранить их в памяти.(