performance - 指数线性增长 - 性能下降

Question

我们有 4 个分片，每个分片都有 14GB 的索引
每个分片有一个主和 3 个从(每个有 32GB RAM)

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

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

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

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

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

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

有没有其他方法可以配置我们的服务器，以便即使索引大小增加一倍或三倍也不影响性能？

Answer 1

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

每个索引的总大小为 14GB，这对 SOLR 基本上没有任何意义。要真正感受性能，索引的术语的唯一性是什么？一个 14GB 的数据索引，一遍又一遍地包含一个单词“cat”，速度会非常快。

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

架构

存储字段

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

省略规范

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

省略TermFreqAndPositions

可以关闭，减少内存，提高性能。

系统

优化核心/索引(段数)

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

术语索引间隔/频率

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

分配过多的 Ram

Solr 在操作系统级磁盘缓存和分面时使用的 RAM 之间进行良好分割时效果最佳，您会惊讶地发现，您实际上可以通过调整其他参数来获得更好的性能，这些参数会降低所需的 ram 使用量并为磁盘释放资源。