Недостаточно памяти на всех раверах Solr того же осколка

Question

Мы используем Apache Solr 3.5 для поиска нашего каталога по каталогу. Мы используем функцию свертывания поля с несколькими осколками, каждый из которых поддерживает кластер только для чтения.

В последнее время мы столкнулись с ошибками Ошибки памяти для всех подчиненных определенного осколка. Мы используем поле, свернувшееся на конкретном поле, которое имеет только одно конкретное значение для всех документов осколка, чьи подчиненные устройства вышли из памяти. Интересно, что ошибка «Недостаточная память» повторялась несколько раз в течение дня (около 4 раз за 24 часа) без какого-либо значительного отклонения трафика от нормального. Максимальный размер кучи, назначенный каждому подчиненному устройству, составляет 8 Гб на машине 16 Гб.

С тех пор мы сделали следующее, и проблема будет арестован сейчас -

1. Добавлено более горизонтальных рабов к проблеме причиняя подчиненной группы, от 3 мы привели это до 6.
2. Мы увеличили интервал опроса репликации с 5 минут до 20 минут. Мы выяснили, что фоновый процесс SolrSearchIndexer.warm потребляет максимальное количество кучи (около 6 Гб), точно когда запросы начинают выходить из памяти. Поскольку интервал репликации вызывает потепление поисковиков, мы думали об увеличении частоты.
3. Мы уменьшили минимальное распределение кучи на tomcat на всех подчиненных этой группе до 1 ГБ. Раньше это было 4Gb.
4. Один из 3-х проблемных рабов имел ошибки write.lock на неиспользуемом ядре. С тех пор мы удалили неиспользуемое ядро ​​на всех подчиненных, поскольку оно было реплицировано из другого мастера Solr. В неиспользуемом ядре было около 1,5 миллионов документов, которые потребляют около 605 Мб на диске.
5. Мы отбросили весь индекс на всех подчиненных и воспроизвели все с нуля. Кстати, у одного из рабов был необычно большой размер индекса на диске - 2,2 Гб по сравнению с 1 Гб на других подчиненных.

Типичный размер индексной директории в проблеме осколка составляет около 1 ГБ, всего около 1 миллиона документов. Прослушивание средних запросов составляет около 10 секунд для каждого ведомого.

Мы попытались воспроизвести все журналы в течение дня в тестовой среде, но как-то тестовый solr никогда не выходит из памяти с одинаковыми настройками кучи. Честно говоря, мы не уверены, что этого больше не повторится.

Может кто-нибудь сказать, что может быть проблемой здесь? Любая помощь будет принята с благодарностью.

Спасибо,

Tushar

Answer 1

Когда-то это было тихо, но я думаю, будет полезно разделить причину здесь. На нашем веб-сайте был соскаблирован кто-то, кто использовал очень большой стартовый параметр в запросах. Распределенный индекс Solr имеет ограничение на размер начального параметра (превышение на 500000).Недостаточная память имела место, когда произошла тяжелая репликация, и координирующий осколок уже имел много документов в памяти, поступающих с входящих узлов из-за высокого начального параметра.

Подробности можно найти здесь - https://wiki.apache.org/solr/DistributedSearch#Distributed_Searching_Limitations

Наше решение было поставить крышку от параметра запуска до 1000, как люди редко выходят за пределы первых нескольких страниц листинга.

Answer 2

Я подозреваю, что речь идет об определении кэшей. Сколько поисковиков вам разрешено проживать параллельно (по умолчанию 2, но вы можете изменить)? Обогреватель Searcher на самом деле является разминкой кеша, поэтому, если у вас есть рабочий поисковик и поисковый нагреватель, он занимает в два раза больше объема памяти. Какие кеши вы используете (документ/запрос/фильтр/поле/пользовательский)? Вы широко используете фасеты (они используют внутренний кеш поля)? Много разных запросов фильтра (FQ) (опять же, кэшированное растровое изображение)? Я думаю, что сбой поля также использует кеш поля.