Solr/Lucene fieldCache OutOfMemory 错误排序动态字段答案

【问题标题】：Solr/Lucene fieldCache OutOfMemory error sorting on dynamic fieldSolr/Lucene fieldCache OutOfMemory 错误排序动态字段
【发布时间】：2012-11-15 07:40:26
【问题描述】：

我们有一个 Solr 核心，它有大约 250 个TrieIntFields（声明为dynamicField）。我们的 Solr 索引中有大约 1400 万个文档，许多文档在其中许多领域都具有一定的价值。我们需要在一段时间内对所有这 250 个字段进行排序。

我们面临的问题是底层的 lucene fieldCache 很快就会被填满。我们有一个 4 GB 的盒子，索引大小为 18 GB。在对这些动态字段中的 40 或 45 个进行排序后，内存消耗约为 90%，并且我们开始出现 OutOfMemory 错误。

目前，如果消耗的总内存超过 80%，我们每分钟都会运行一个 cron 作业来重新启动 tomcat。

根据我的阅读，我了解到限制可排序 Solr 字段上不同值的数量会降低 fieldCache 空间。这些可排序字段中的值可以是 0 到 33000 之间的任何整数，并且分布非常广泛。我们想到了一些扩展解决方案，但处理整个问题的最佳方法是什么？

更新：我们认为不是排序，如果我们确实提升它不会去 fieldCache。所以不要发出像

这样的查询

select?q=name:alba&sort=relevance_11 desc

我们试过了

select?q={!boost relevance_11}name:alba

但不幸的是，boosting 也会填充字段缓存:(

【问题讨论】：

标签： solr lucene out-of-memory

【解决方案1】：

我认为你有两个选择：

1) 添加更多内存。
2）通过指定facet.method=enum、as per documentation来强制Solr不使用字段缓存。

还有solr-user mailing list thread 讨论同样的问题。

除非您的索引很大，否则我会选择选项 1)。现在 RAM 很便宜。

【讨论】：

facet.method 不是仅适用于方面查询吗？如何禁用排序查询的字段缓存？
虽然增加内存是一种显而易见的解决方案，但我们的服务器由机架空间托管，一台 4 GB 服务器的成本为 175 美元/月，而一台 15 GB 的服务器（几乎可以容纳我们整个 Solr 索引）的成本为 657 美元/莫（见rackspace.com/cloud/pricing）。在为我们甚至不需要的缓存投入更多资金之前，我想找到完全避免它的方法。
我邮寄了 solr 用户列表。 Erick Erickson 说：“考虑到这些限制，我肯定看不出这是如何工作的。只是为了保存这些值，假设每个文档在 150 个字段中保存一个值，你需要 150 * 4 * 14,000,000 或 8.4G 的内存，而你只是没有那么多内存可以玩。对于 14M 文档来说，分片似乎很愚蠢，但这可能是必要的。或者获得具有大量内存的硬件。或者重新定义问题，这样你就不必排序了很多领域。不太确定如何做到这一点，但是“所以我们现在正在重新设计我们的模式！我接受你的回答
感谢分享，这个很有意思。

【解决方案2】：

我们有一种方法可以通过保留单个排序字段来重新设计架构。我们拥有的动态字段类似于relevance_CLASSID。当前模式具有唯一键 NODEID 和多值字段 CLASSID - 相关性分数适用于这些类 ID。如果我们改为为每个 nodeId 每个 classId 保留一个文档，即新模式将 NODEID:CLASSID 作为唯一键，并在具有相同 NODEID 的文档中存储一些冗余信息，那么我们可以对单个字段 relevance 进行排序并执行过滤 CLASSID 上的查询。

【讨论】：