1

我们的 ES 相当慢，我们还没有优化它（和查询），但是根据这个链接，来自 Elastic 的请求拒绝是一种反馈形式，要求放慢速度并调整批量的大小。

我们构建了一种背压形式，其中阻塞批量的大小（同时发送的单个请求的列表，我们还没有使用 MSearch）取决于前一个批量中拒绝了多少请求。在开始新的批量之前，我们等待当前批量完成。显然，所有被拒绝的请求都被重新注入到请求队列中（以构造查询所需的数据的形式）。例如，如果我们的 Elastic 可以同时处理 500 个请求，而我们发送 600 个请求，其中一些将被拒绝，新的大小将减少到 480 个（20% 折扣）。

我们发现ES 对先前拒绝的请求返回不同的结果。例如，它可能会返回类似于预期结果的结果，但偏移量为 2。我们还缺少地址应该有 1 个结果的结果，但由于这个错误而没有结果。

如果批量大小小于 ES 可以处理的阈值，那么一切都会按预期进行，我们会得到预期的结果。

看起来这不是图书馆的（elastic4s）问题。

弹性配置：2 个节点，每个节点 5 个分片

每个节点：2 个 CPU、32 GB 内存、16 GB 堆。其他都是默认的

我在网上找不到任何信息，有人遇到过这个问题吗？解决方案是什么？

到目前为止，我们尝试了什么：

  • Thread.sleep正如上面的链接所暗示的那样，在批量之间。

  • 删除查询级别的缓存以及从索引中删除它。

  • 在不同的（较慢的）硬件上尝试相同的索引。

  • 验证这不是竞争条件（在我们的代码中）问题。

更新：

查询是什么样的。

用于搜索的线程池： "search" : { "type" : "fixed", "min" : 4, "max" : 4, "queue_size" : 1000 },

第二次更新：

我们还尝试为我们的查询设置偏好（认为这是分片的问题）：.preference(Preference.Primary)没有积极的结果（它们比以前更加随机）。使用此设置的两次连续运行会给出不同的“随机”结果，因此这是不一致的。

4

1 回答 1

0

结果不一致的原因是，Success如果至少 1 个分片有结果，Elastic 会回复。所以基本上，如果我们的 5 个分片中只有一个成功，那么请求将返回一个只有 20% 数据的成功结果。

如这里和这里所见，这不是错误，这是一项功能。Elastic 更喜欢返回一些（尽管不一致的）结果，而不是不返回任何东西。

这个问题的解决方案是要么只使用一个分片，要么使用每个 ES 响应具有的以下对象将超过 0 个失败的分片视为一般请求失败：

"_shards" : { "total" : 5, "successful" : 5, "failed" : 0 },

于 2017-02-22T10:44:35.787 回答