Solr服务器内存和磁盘空间

Question

上下文

我有一个AWS EC2实例

• 8Gb RAM
• 8Gb的磁盘空间

使用

运行 Solr 5.1.0

• 2048Mb的Java堆
• -Xms2048m -Xmx2048m

额外:(更新）

• 在服务器上生成日志
• 进口间隔10秒（总是三角洲）
• 从数据库导入（JdbcDataSource）
• 我认为我现在没有配置任何优化策略
• GC分析？我不知道。
• 我怎样才能知道这些字段有多大......什么是大字？

情况：

Solr上的索引有200,000个文档，每秒查询不超过一次。但是，在大约10天内，服务器的内存和磁盘空间达到90％ - 可用空间的95％。

在调查磁盘使用情况sudo du -sh /时，它只返回2.3G的总计。不如df -k告诉我的那样多（Use% -> 92%）。

我可以通过重新启动Solr服务解决问题。

我缺少什么？ Solr如何消耗所有内存和磁盘空间以及如何防止它？

@TTT的额外信息

很抱歉延迟，但过去几天我一直在监控Solr生产服务器。你可以在这里看到一个综述： https://www.dropbox.com/s/x5diyanwszrpbav/screencapture-app-datadoghq-com-dash-162482-1468997479755.jpg?dl=0 Solr的当前状态：https://www.dropbox.com/s/q16dc5t5ctl32od/Screenshot%202016-07-21%2010.29.13.png?dl=0 我在监控开始时重新启动了Solr，现在，2天后，我发现磁盘空间以每天1,5Gb的速度下降。 如果您需要更多细节，请告诉我。

• 每天删除的文档数量不多。我们说最多每天50 - 250。
• Solr的当前日志目录：ls -lh /var/solr/logs - ＆gt; total 72M
• 没有主从设置
• 导入器运行10秒钟，但每次导入的文档不超过10-20个。每晚都会发生3k-4k文档的大量导入。 Solr当时没有采取太多行动。
• 没有大字段，最大字段最多可包含255个字符。

随着监控的到位，我测试了最常见的查询。它确实包含分面（字段，查询），排序，分组......但我并没有真正影响堆和gc计数的各种指标。

Answer 1

首先，访问your.solr.instance:[port]/[coreName]/admin/system并检查Solr实际使用的资源数量。 memory和system元素对您最有用。它可能是盒子上的其他东西，至少是一些资源使用的罪魁祸首。

对我来说，你可以通过重新启动Solr尖叫“查询和导入令人讨厌的”内存来“解决”这个问题。对于磁盘空间，如果它是后面的日志文件，我不会感到惊讶。我还想知道你是否最终会收到很多旧的，已删除的文件，因为你需要进行大量的delta导入，直到Solr自动删除它们。实际上，如果您转到http://your.solr.instance:[port]/solr/#/[coreName]，您应该能够看到索引中有多少已删除的文档。如果数量非常非常大，您应该在低使用率期间安排时间来运行优化以消除它们。

另请注意，Solr似乎倾向于尽可能多地填充给定的堆空间。

由于日志是在服务器上生成的，因此请检查其中有多少日志存在。 4.10之后的Solr有一个生成大量日志文件的恶习，这可能会导致磁盘空间问题，尤其是导入频率。有关如何处理Solr对伐木的热爱的信息，我将在Solr 5.1: Solr is creating way too many log files参考我的自我回答。基本上，您需要导航到solr启动脚本以禁用Solr的日志备份，然后将其替换为您自己的解决方案。

如果您有主从设置，请检查从属设备是否正在备份某些配置文件，例如schema.xml或solrconfig.xml。

根据每个delta导入的记录数量，您可能会有相互重叠的提交，这将影响您的盒子上的资源使用情况。如果您在日志中阅读了有关重叠ondecksearchers的任何内容，那么这绝对是一个问题。

许多三角洲进口也意味着许多提交。提交是一项相当繁重的操作。您需要在多个文档之后将solrconfig.xml调整为软提交，稍后再进行一次硬提交。如果您批量执行提交，那么频繁的增量应该会产生较小的影响。

如果要加入导入列，则可能需要为数据库中的已加入列编制索引。如果您的数据库与Solr不在同一台计算机上，则网络延迟可能是一个问题。这是我过去一直在努力的一个。如果数据库在同一台机器上并且您需要索引，那么不进行索引肯定会对您的机器资源产生负面影响。

在Solr上使用VisualVM之类的东西来查看堆使用情况和GC可能会有所帮助。你想确保没有快速增加使用量，你还要确保GC没有一堆可能导致你的盒子出现怪异的世界各地的收藏。

优化是一项非常密集的操作，在4.10之后，您根本不需要经常使用（如果有的话）。但是，有些人仍然会这样做，如果您有大量已删除的文档，那么对您来说可能会有所帮助。如果您决定采用优化策略，则应仅在使用率较低时进行，因为优化会使索引的大小暂时加倍。优化合并段并删除标记为通过增量删除的文件。

“大字段”是指其中包含大量数据的字段。您需要查找正在使用的每种字段类型的大小限制，但如果您针对特定字段运行最大大小，则可能需要尝试找到减小数据大小的方法。或者，您可以省略将这些大列导入Solr，而是在从Solr获取特定文档后从源DB中的列中检索数据。这取决于您的设置和您的需求。你可能会或可能不会做很多事情。如果你让其他一切运行得更有效率，你应该没问题。

您运行的查询类型也会导致问题。大量的排序，刻面等可能非常耗费内存。如果我是你，我会将VisualVM挂钩到Solr，这样我就可以查看堆使用情况和GC，然后使用典型查询加载测试Solr。

Answer 2

我终于设法解决了这个问题。所以我回答了我自己的问题。

我在log4j.properties文件中更改/添加了以下行，该文件位于/var/solr/（我的情况下为Solr根位置）。

# log4j.rootLogger=INFO, file, CONSOLE
# adding:
log4j.rootLogger=WARN, file, CONSOLE

降低日志记录级别。

# adding:
log4j.appender.file.Threshold=INFO

设置记录阈值。

您可以在下面的图表中看到，截至9月2日，磁盘使用情况应该是稳定的。服务器上的内存消耗也是如此。