Много мыслей на эту тему.Хотя мой ответ никак не использует EhCache.
Во-первых, я не верю, что документы должны храниться в вашем поисковом индексе.Содержимое поиска должно храниться там, а не весь документ.Я имею в виду, что из вашего поискового запроса должны быть идентификаторы документов.Не содержание самих документов.Сами документы должны храниться и извлекаться из второй системы, вероятно, исходного хранилища файлов, из которого они проиндексированы.Это уменьшит размер индекса, уменьшит размер кэша вашего документа, уменьшит время репликации главного подчиненного (это может стать узким местом, если вы часто обновляете) и уменьшит накладные расходы при написании ответов на поиск.
Далее рассмотрите возможность установки обратногоHTTP прокси перед Solr.Хотя кеши запросов позволяют Solr быстро реагировать, кеш, подобный Varnish, находящемуся перед Solr, еще быстрее.Это выгружает Solr, позволяя ему тратить время на ответы на запросы, которых он раньше не видел.Второй эффект заключается в том, что теперь вы можете использовать большую часть своей памяти для кэширования документов вместо кэшей запросов.Если вы следовали моему первому предложению, ваши документы будут невероятно маленькими, что позволит вам хранить большую часть, если не все, в памяти.
Краткий обзор расчетов конвертов для форматов документов.Я могу легко предоставить 32-битный int как идентификатор для 150 миллионов документов.У меня все еще есть 10-кратный запас для роста документа.150 миллионов удостоверений занимают 600 МБ.Добавьте фактор выдумки для упаковки документов Solr, и вы, вероятно, сможете легко кэшировать все ваши документы Solr в 1–2 ГБ.В наше время легко получить 12ГБ-24ГБ или ОЗУ, и я бы сказал, что вы можете сделать все это на одной коробке и получить невероятную производительность.Не нужно ничего постороннего, такого как EhCache.Просто убедитесь, что вы используете свой поисковый индекс максимально эффективно.
Относительно GC: я не видел много времени, проведенного GC на моих серверах Solr.Большая часть того, что нужно было собрать, - это очень недолговечные объекты, связанные с циклом HTTP-запросов и ответов, которые никогда не выходят из пространства eden.При правильной настройке кэши не имели высокого оборота.Единственные большие изменения произошли, когда новый индекс был загружен и кэши были очищены, но это не происходило постоянно.
РЕДАКТИРОВАТЬ: Для фона я потратил значительное время на настройку кэширования Solr для большой компании, которая продает консолии обслуживает миллионы запросов в день со своих серверов Solr.