performance - 如何提高 ElasticSearch 中的过滤器性能？

Question

总结

我们需要提高渗滤器性能(吞吐量)。

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

问题

如何正确横向扩展？

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

2) ElasticSearch server如果只做percolation需要多少内存？

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

3) 拥有 SSD 是否会对渗滤器的性能产生有意义的帮助，还是增加 RAM 和/或节点数量更好？

我们的现状

我们的职位索引中有 200,000 个查询(求职提醒)。我们能够运行 4 个调用 percolator 的并行队列。每个查询都能够在大约 35 秒内过滤 50 个作业，因此我们可以过滤:

4 queues * 50 jobs per batch / 35 seconds * 60 seconds in minute = 343 jobs per minute

我们需要更多。

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

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

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

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

[2015-03-04 09:46:22,221][DEBUG][action.percolate ] [Cletus Kasady] [jobs][3] Shard multi percolate failure org.elasticsearch.action.NoShardAvailableActionException: [jobs][3] null

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

相关: How to Optimize elasticsearch percolator index Memory Performance

Answer 1

答案

如何正确横向扩展？

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

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

问: 2)ElasticSearch服务器只做percolation需要多少内存？

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

答:过滤器索引完全驻留在内存中，所以答案是很多。这完全取决于索引的大小。根据我的经验，200 000 次搜索需要 50MB 的索引。在内存中，该索引将占用大约 500MB 的堆内存。因此，如果您正在运行，4 GB RAM 应该足够了。我会建议您使用更多节点。但是，随着索引大小的增长，您将需要添加 RAM。

问: 3) 拥有 SSD 是否会对渗滤器的性能产生有意义的帮助，还是增加 RAM 和/或节点数量更好？

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

编辑:不要相信我对那些内存估计的话。查看site plugins在主要的 ES 网站上。我找到了 Big Desk特别有助于观察性能计数器以进行扩展和规划。这应该会为您提供更多关于估计您的具体要求的有值(value)的信息。

编辑以回应@DennisGorelik 下面的评论:

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

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