如何提高 ElasticSearch 中的渗透器性能？

Question

总结

我们需要提高过滤器性能（吞吐量）。

最可能的方法是扩展到多台服务器。

问题

如何正确横向扩展？

1) 增加底层索引中的分片数量是否允许并行运行更多渗透请求？

2) 如果 ElasticSearch 服务器只做渗透，它需要多少内存？

2 台 4GB RAM 的服务器还是一台 16GB RAM 的服务器更好？

3) 使用 SSD 会显着提高渗透器的性能，还是增加 RAM 和/或节点数量更好？

我们目前的情况

我们的职位索引中有 200,000 个查询（职位搜索提醒）。 我们能够运行 4 个调用 percolator 的并行队列。 每个查询能够在大约 35 秒内过滤 50 个作业的批次，因此我们可以过滤一下：

4 个队列 * 每批 50 个作业 / 35 秒 * 每分钟 60 秒 = 343 每分钟作业数

我们需要更多。

我们的工作索引有 4 个分片，我们正在使用位于该工作索引之上的 .percolator。

硬件：2 个处理器的服务器，总共 32 个内核。 32GB 内存。 我们为 ElasticSearch 分配了 8GB RAM。

当 percolator 工作时，我上面提到的 4 个 percolation queue 会消耗大约 50% 的 CPU。

当我们尝试将并行渗透队列的数量从 4 个增加到 6 个时，CPU 利用率跃升至 75% 以上。 更糟糕的是，percolator 开始因 NoShardAvailableActionException 而失败：

[2015-03-04 09:46:22,221][DEBUG][action.percolate][Cletus Kasady] [jobs][3] Shard 多渗透失败 org.elasticsearch.action.NoShardAvailableActionException：[工作][3] 空

该错误似乎表明我们应该增加分片的数量并最终添加专用的 ElasticSearch 服务器（+ 稍后增加节点的数量）。

相关： How to Optimize elasticsearch percolator index Memory Performance

Answer 1

答案

如何正确横向扩展？

问： 1) 增加底层索引中的分片数量是否允许并行运行更多渗透请求？

答：不。分片仅在创建集群时才真正有用。单个实例上的附加分片实际上可能会降低性能。一般来说，分片的数量应该等于节点的数量以获得最佳性能。

问： 2) ElasticSearch 服务器如果只做渗透，需要多少内存？

2 台 4GB RAM 的服务器还是一台 16GB RAM 的服务器更好？

答： 渗透指数完全驻留在内存中，因此答案很多。这完全取决于索引的大小。根据我的经验，200 000 次搜索需要 50MB 的索引。在内存中，该索引将占用大约 500MB 的堆内存。因此，如果这就是您正在运行的全部内容，那么 4 GB RAM 应该足够了。在您的情况下，我会建议更多节点。但是，随着索引大小的增长，您将需要添加 RAM。

问： 3) 使用 SSD 是否会显着提高 percolator 的性能，或者增加 RAM 和/或节点数量会更好？

答：我对此表示怀疑。正如我之前所说，过滤器驻留在内存中，因此磁盘性能不是太大的瓶颈。

编辑：不要相信我对那些内存估计的看法。查看 ES 主站点上的 site plugins。我发现Big Desk 对于查看性能计数器以进行扩展和规划特别有用。这应该会为您提供更多有价值的信息来估计您的具体要求。

编辑以下@DennisGorelik 的评论：

这些数字纯粹是通过观察得到的，但经过反思，它们是有道理的。

1. 200K 查询到 50MB 磁盘：这个比率意味着当序列化到磁盘时平均查询占用 250 字节。
2. 堆上的 50MB 索引到 500MB： 我们在内存中处理 Java 对象，而不是磁盘上的序列化对象。考虑反序列化 XML（或任何数据格式），您通常会得到 10 倍大的内存对象。