指数线性增长 - 性能下降

Posted 2023-02-23

【中文标题】指数线性增长 - 性能下降

【英文标题】：Index linear growth - Performance degradation

【发布时间】：2012-08-10 01:40:30

【问题描述】：

我们有 4 个分片，每个分片都有 14GB 索引 每个 shard 有一个 master 和 3 个 slave（每个都有 32GB RAM）

我们预计索引大小将在不久的将来增长一倍或三倍。 所以我们考虑将我们的索引合并为 28GB 索引，这样每个分片就有 28GB 的​​索引，并将每个从属服务器上的 RAM 增加到 48GB。

我们在本地进行了此更改并通过向具有 14GB 和 28GB 索引的每台服务器发送相同的 10K 实际查询来测试服务器，我们发现

对于具有 14GB 索引（48GB RAM）的服务器：搜索时间为 480 毫秒，索引命中数：3.8G

对于具有 28GB 索引（48GB RAM）的服务器：搜索时间为 900 毫秒，索引命中数：7.2G

所以我们看到，将整个索引放在 RAM 中并不能帮助维持搜索时间方面的性能。当索引大小增加一倍时，搜索时间线性增加一倍。

我们原本考虑只保留 4 个分片配置，但现在看来我们必须为每个分片添加另一个分片或另一个从属。

是否有任何其他方式可以配置我们的服务器，以便即使索引大小翻倍或翻三倍也不影响性能？

【问题讨论】：

你给JVM多少内存？如果您为 JVM 提供了超过 20G 的内存，这意味着在第一次测试时索引完全在操作系统缓存中，但在第二次测试中没有，并且缓存中的所有索引在性能方面有很大的不同。 .

随着索引大小的增长，性能下降是正常的，但由于 Zipf 定律，我希望它是次线性的，所以你的结果让我有点惊讶。

【参考方案1】：

我不想说这取决于，但它...取决于。

每个索引的总大小为 14GB，这对 SOLR 来说基本上没有什么意义。要真正了解性能，索引术语的独特性是什么？一次又一次地索引一个 14GB 的数据，其中包含一个单词“cat”会非常快。

您还确认您需要以下功能，禁用它们可以大大提高性能：

架构

存储字段

您需要存储字段吗？删除它可以大大提高性能（您可以安全地拥有一个没有任何存储字段的整个索引，并完全依赖 solr 中的 facets、pivot 和其他功能来驱动 UX）。

省略规范

在某些情况下，您可以将此标志设置为 false 以总体上减少内存并提高性能。

省略TermFreqAndPositions

可以关闭，总体上减少内存并提高性能。

系统

优化核心/索引（段数）

在处理较大的索引大小时，索引优化很重要。确保每个核心都经过优化，并且当您查看核心时，它会显示段数 = 1。我发现，当您增加索引大小时，这会发挥更重要的作用（这会影响操作系统级别的文件缓存和事实读取一个大文件比读取多个小文件更容易）是的，确实有 1.71 亿多个文档。

术语索引间隔/频率

如果您有一个或多个字段包含非常独特的值（例如 GUID/UUID 或通常的唯一 ID），则可能需要配置术语索引间隔（默认为 256）。通常，TIF 越低，您需要的内存越多，TIF 越高，您需要的内存越少，但您可能需要的磁盘寻道次数越多。

内存分配过多

Solr 在 OS 级磁盘缓存和分面时使用的 RAM 之间的良好分离时效果最佳，您会惊讶地发现，您实际上可以通过调整其他参数来获得更好的性能，从而降低所需的 ram 使用率并释放磁盘资源。

【讨论】：

如果您支持突出显示，您将需要存储字段，这是任何搜索的重要组成部分。