Рекомендации по производительности Solr

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

Twitter  - 26874747
Core2    -  3027800
Core3    -  6074253

Конфигурация моего сервера имеет 8 ГБ ОЗУ, но теперь мы наблюдаем падение производительности сервера. Что можно сделать, чтобы улучшить это? Кроме того, у меня есть несколько вопросов.

Занимает ли количество коммитов большой объем памяти? Поможет ли уменьшение количества коммитов в час? Большинство моих запросов основаны на гранях поля или даты? как их улучшить?

С уважением, Рохит


solr solrj
person sesmic    schedule 15.07.2011    source источник

Ответы (3)


arrow_upward
3
arrow_downward

  • Поскольку у вас большое количество коммитов, вы можете увеличить коэффициент слияния, чтобы улучшить производительность индексирования.
  • Индексируйте документы партиями, а не по одному.
  • Когда происходит слияние, требуется очень много памяти/процессора, а также в это время блокируется индексация.
  • Отделите сервер индексации от сервера запросов для повышения производительности, используйте конфигурацию ведущий-ведомый.
person KaKa    schedule 17.07.2011

arrow_upward
0
arrow_downward

Мы также столкнулись с падением производительности в Solr с момента нашей первоначальной установки, лучшее, что я нашел, это это: http://www.lucidimagination.com/blog/2010/01/21/the-seven-deadly-sins-of-solr/

Это должно привести вас прямо к некоторым улучшениям вашей реализации Solr. На данный момент мои выводы говорят о том, что:

  • Используйте SolrJ для повышения производительности с помощью бинарных обновлений (он добавляет документы в индекс, но не требует фиксации... нам пришлось отказаться от PHP и перенести бэкэнд на Java)
  • Удалите процесс оптимизации из каждой фиксации и запускайте его только один раз в день/неделю в зависимости от объема имеющихся у вас данных (по умолчанию он настроен на запуск при каждой фиксации в библиотеке php-solr-client).
  • Настройте свои прогревочные запросы на данные, с которыми вы столкнулись чаще всего.
  • Фиксируйте большие куски данных.
  • Мониторинг JVM и сборщика мусора
  • Настройте параметры Tomcat/Java
person Osvaldo Mercado    schedule 27.07.2011

arrow_upward
0
arrow_downward

Обновите до последней магистрали SOLR 4.0. Затем следуйте инструкциям здесь: http://wiki.apache.org/solr/NearRealtimeSearch.

Ключом к решению является использование программных коммитов при импорте твитов.

Мы используем систему, аналогичную той, которую вы описываете, и индексируем около 500 000 твитов в час без сучка и задоринки.

Часть проблемы здесь заключается в том, что вы не можете настроить слишком много кэширования в этой среде, потому что вам нужно будет зафиксировать в какой-то момент. Когда это происходит, кеш исчезает, и срабатывает автопрогрев. Обязательно посмотрите настройки автопрогрева. Также проверяйте журналы при выполнении запросов фасетов на наличие указаний на то, что количество уникальных значений в любом из фасетов не слишком велико. Мы все еще боремся с поворотными запросами с 6 миллионами уникальных пользователей. Это убивает вашу производительность. На практике это означает, что у нас все в порядке с 50 миллионами твитов или около того, при превышении этого значения скорость значительно замедляется, и мы ждем некоторых улучшений версии 4.0, чтобы решить эту проблему.

person ReDeVries    schedule 14.02.2012