Реплики Solrcloud поступают в режим восстановления сразу после обновления

Question

У нас есть кластер облачного сервера solr с 10 осколками и 4 репликами в каждом осколке в нашей стрессовой среде. В нашей среде prod у нас будет 10 осколков и 15 реплик в каждом осколке. Наши текущие настройки фиксации следующие:

*<autoSoftCommit> 
     <maxDocs>500000</maxDocs> 
     <maxTime>180000</maxTime> 
    </autoSoftCommit> 
    <autoCommit> 
     <maxDocs>2000000</maxDocs> 
     <maxTime>180000</maxTime> 
     <openSearcher>false</openSearcher> 
    </autoCommit>* 

Мы проиндексировали примерно 90 миллионов документов. У нас есть два разных способа индексирования документов: a) Полная индексация. Требуется 4 часа для индексации 90 миллионов документов, а скорость поступления документов в поисковик составляет около 6000 в секунду. b) Инкрементное индексирование. Для индексированных дельта-изменений требуется час. Примерно 3 миллиона изменений и скорость поступления документов в поисковиков составляет 2500 в секунду

У нас есть две коллекции search1 и search2. Когда мы делаем полную индексацию, мы делаем это в коллекции search2, в то время как search1 обслуживает прямой трафик. По завершении мы свопим коллекцию с использованием псевдонимов, чтобы коллекция search2 обслуживала прямой трафик, а search1 стал доступен для следующего полного прогона индексации. Когда мы делаем инкрементную индексацию, мы делаем это в коллекции search1, которая обслуживает прямой трафик.

Все наши поисковые устройства имеют доступную 12 ГБ оперативной памяти и имеют четырехъядерный процессор Intel® Xeon (R) X5570 @ 2.93GHz Мы наблюдали следующую проблему при запуске индексации. Примерно через 10 минут после запуска индексации на 14 параллельных хостах реплики входят в режим восстановления. Это происходит со всеми осколками. Примерно через 20 минут все больше и больше реплик начинают переходить в режим восстановления. Примерно через полчаса все реплики, кроме лидера, находятся в режиме восстановления. Мы не можем дросселировать индексную нагрузку, так как это увеличит общее время индексирования. Поэтому, чтобы преодолеть эту проблему, мы удалим все реплики, прежде чем запускать индексирование, а затем добавим их после завершения индексации.

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

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

Мы пробовали различные фиксации настройки, как показано ниже

а) Нет автоматический мягкий не совершать, не авто трудно не совершать и совершают срабатывают в конце индексация б) Нет автоматической мягкий не совершат, да авто трудно совершить и фиксация в конце индексации
с) Да авто мягкой фиксацией, нет авто трудно не совершать
г) Да авто мягкой фиксации, да авто трудно совершать
е) Различные настройки частоты для фиксаций на выше

К сожалению, все вышеизложенное дает такое же поведение. Реплики все еще восстанавливаются Мы увеличили тайм-аут zookeeper с 30 секунд до 5 минут, и проблема не устранена. Есть ли какие-либо настройки, которые могли бы исправить эту проблему?

Answer 1

Паузы сбора мусора могут превышать clientTimeout, в результате чего соединение Zookeeper прерывается, что вызывает бесконечный цикл восстановления.

Частое исправление, фиксация или обновление, а также плохо настроенная конфигурация слияния сегментов может привести к чрезмерным накладным расходам при восстановлении. Эти издержки могут вызвать цикл восстановления.

И, наконец, существует некоторая ошибка, которая может возникнуть во время восстановления, которое испытала наша организация. Это редко, но, похоже, это происходит в то время, когда сетевые соединения раздуваются или ненадежны. Zookeeper отключает триггер восстановления, а восстановление восстанавливает память, иногда это может даже вызвать состояние нехватки памяти.

UpdateBEWARE GRAPH Запрашивает

организации я работаю на опытные паузы из графа запросов в рамках Solr. Запросы в графе были отдельно от плагина/компонента типа вперед. Когда кто-то подавал длинные строки для типа «вперед», запрос графа становился сложным и вызывал огромное использование памяти и gc-паузы.