Solr Performance Предложения - PullRequest
Новая
       10

Solr Performance Предложения

1 голос
/ 15 июля 2011

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

Twitter  - 26874747
Core2    -  3027800
Core3    -  6074253

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

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

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

Ответы [ 3 ]

3 голосов
/ 17 июля 2011
  • Поскольку у вас большое количество коммитов, вам может потребоваться больший коэффициент слияния для повышения производительности индексирования.
  • Индексируйте документы пакетами, а не один за другим.
  • При слиянии требуется очень большой объем памяти / процессор, в это время индексирование также блокируется.
  • Отдельный сервер индексирования для сервера запросов для повышения производительности, используйте конфигурацию master-slave.
0 голосов
/ 15 февраля 2012

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

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

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

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

0 голосов
/ 28 июля 2011

Мы также испытали падение производительности в 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
...