Улучшение производительности Solr

Question

Я развернул 5-осколочную инфраструктуру, где: Shard1 имеет 3124422 документов shard2 имеет 920414 документов shard3 имеет 602772 документа Shard4 имеет 2083492 документов shard5 имеет 11915639 документов Общий размер индексов: 100 ГБ

Операционная система - Linux x86_64 (Fedora выпуск 8) с vMem, равным 7872420, и я запускаю сервер, используя Jetty (из примера загрузки Solr) с: java -Xmx3024M -Dsolr.solr.home = многоядерный -jar start.jar

Время ответа на запрос составляет около 2-3 секунд. Тем не менее, если я выполняю несколько запросов одновременно, производительность сразу падает: 1 одновременный запрос: 2516мс 2 одновременных запроса: 4250,4469 мс 3 одновременных запроса: 5781, 6219, 6219 мс 4 одновременных запроса: 6484, 7203, 7719, 7781 мс ...

Использование JConsole для мониторинга процесса java сервера. Я проверил, что память кучи и загрузка ЦП не достигают верхних пределов, поэтому сервер не должен работать как перегруженный. Может ли кто-нибудь дать мне подход к настройке экземпляра, чтобы он не зависел от количества одновременных запросов?

Заранее спасибо

Answer 1

Как я отмечал в списке рассылки Solr, где вы задали тот же вопрос 3 дня назад, Solr / Lucene чрезвычайно выигрывает от использования SSD. Хотя для большего количества операций ввода-вывода будет работать разделение на большее количество компьютеров или добавление загрузочных ОЗУ, опция SSD сравнительно дешевая и чрезвычайно простая.

Купите Intel X25 G2 (409 долл. В NewEgg за 160 ГБ) или один из новых твердотельных накопителей на базе SandForce. Поместите свои существующие 100 ГБ индексов и посмотрите, что произойдет. Это пол дня работы, топы. Если это бомбы, очистите диск для вашей рабочей станции. Вы будете очень довольны повышением производительности, которое оно дает вам.

Answer 2

Возможно, вы захотите создать рабов для каждого сегмента, чтобы можно было поддерживать больше операций чтения (см. http://wiki.apache.org/solr/SolrReplication),, однако производительность, которую вы получаете, не очень разумна.

С учетом времени отклика, которое вы видите, создается впечатление, что ваш диск должен быть горлышком бутылки. Вам может быть дешевле просто загрузить каждый осколок достаточным объемом памяти для хранения полного индекса (по 20 ГБ каждый?). Вы можете посмотреть на доступ к диску с помощью утилиты 'sar' из пакета sysstat. Если вы постоянно получаете более 30% использования диска на любом блюде во время поиска, это хороший признак того, что вам нужно добавить немного памяти и позволить ОС кэшировать индекс.

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