3

概括

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

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

问题

如何正确扩展？

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

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

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

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] 碎片多渗透失败 org.elasticsearch.action.NoShardAvailableActionException: [jobs][3] null

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

相关： 如何优化 elasticsearch percolator index 内存性能

4

1 回答 1

4

答案

如何正确扩展？

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

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

Q: 2) ElasticSearch server 如果只做渗透，需要多少内存？

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

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

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

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

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

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

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

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