На Solr 4.5 есть индекс, который содержит ~ 50К документов, занимающих ~ 4Гб на диске. Физическая оперативная память, доступная для JVM, составляет 6 ГБ (из 10 ГБ на сервере), ОС - 64-битная CentOS 5.
Одно из запросов приложений, которые индексируют несколько раз в цикле, один запрос отправляется сразу после завершения предыдущего, практически без задержки между ними, но все же не одновременно.
Все запросы одинаковы и соответствуют следующему простому шаблону:
(все поля в q индексированные токенизированные текстовые)
После относительно небольшого количества таких запросов (иногда после 3-го, иногда после 5-го и т. Д.) Срабатывает сборщик мусора на стороне Solr, потому что вся память занята. Это приводит к длительной задержке в несколько секунд, прежде чем Solr ответит, что заставляет приложение, отправляющее запрос, прерываться по таймауту.
Если приложение ожидает между последовательными отправками запросов около 1 секунды, все они завершаются быстро, и ОЗУ не исчерпывается; но чем быстрее запросы отправляются один за другим, тем сильнее будут изменения, которые последующие вызовут срабатывание сборщика мусора и нежелательный тайм-аут.
Один и тот же индекс (построенный из одних и тех же данных одним и тем же приложением) абсолютно подходит для той же модели использования в более старой версии Solr (1.4).
Увеличение размеров кеша в solrconfig.xml не имеет большого эффекта, но уменьшает rows значение 10 из 100 делает тайм-аут менее вероятным, хотя и не совсем невозможным. queryResultWindowSize в конфиге по умолчанию установлено 20.
Я предполагаю, что может быть несколько причин наблюдаемого поведения, и я привел недостаточно подробностей. Если да, то что мне нужно изменить или профиль, чтобы сузить круг вопросов?
Юрий, я работаю в Azul Systems. В прошлом году мы опробовали нашу виртуальную машину Zing вместе с Lucene в тестировании производительности. Краткое описание решения, которое мы разработали, показывает репрезентативную статистику задержки на рисунке на второй странице: http://www.azulsystems.com/partners/apache-lucene-solr.
Сборщик мусора Zing "C4" не похож на таковые в Hotspot. Сборка мусора в Zing означает, что весь мир не останавливается. Скорее, потоки мутаторов Java продолжают работать, при этом операции сборки мусора выполняются одновременно, параллельно, обычно на отдельных ядрах. В Zing нет режима остановки мира, ни в основной тактике GC, ни в качестве запасного варианта, как в коллекторах нового, так и в старом поколении.
Я не могу сказать, что мы видели Solr 4.5 как особого виновника. Если вы уверены, что Solr или ваше приложение не содержат ошибки, и у вас все еще есть паузы GC после сортировки, подумайте о том, чтобы взглянуть на Zing: http://www.azulsystems.com/products/zing/whatisit
Комментарии Voretaq7 о плохих альтернативах, должно быть, не включали C4 или Zing. По крайней мере, я на это надеюсь.
Удачи.
Мэтт
Такова природа Java: сборка мусора означает, что весь мир останавливается.
Все известные мне решения, как правило, никуда не годятся:
Так как вы начали испытывать проблемы только после обновления до новой версии Solr, вы можете захотеть проверьте их списки рассылки и в их трекере проблем чтобы узнать, является ли эта проблема известной, решена в более поздней версии.
Если вы хотите профилировать и отлаживать само приложение, это действительно было бы скорее вопросом переполнения стека - возможно, ваш Solr является чем-то неоптимальным (в вашем запросе или в приложении), что заставляет его использовать больше ОЗУ, чем это нужно.