我们的ES相当慢，我们还没有优化它（和查询），但是根据this link，来自Elastic的请求拒绝是一种反馈的形式，要求减慢和调整大小大部分。
我们构建了一种背压形式，其中阻塞批量的大小（同时发送的单个请求列表，我们还没有使用MSearch）取决于前一批量中拒绝了多少请求。我们等待当前的批量完成才能开始新的批量生产。显然，所有被拒绝的请求都被重新注入到请求队列中（以构造查询所需的数据的形式）。例如，如果我们的Elastic可以同时处理500个请求而我们发送600个请求，其中一些将被拒绝，新的大小将减少到480（20％折扣）。
我们发现 ES会针对之前拒绝的请求返回不同的结果。例如，它可能会返回类似于预期结果的内容，但偏移量为2.我们也会丢失结果，其中地址应该有1个结果，但由于此错误而没有结果。
如果批量大小小于ES可以处理的阈值，那么一切都按预期进行，我们会得到预期的结果。
它看起来不像是图书馆的（弹性4）问题。
弹性配置： 2个节点，每个节点有5个分片
每个节点： 2个CPU，32 GB RAM，16 GB堆。其他一切都是默认的
我无法在互联网上找到任何信息，有人有这个问题吗？解决方案是什么？
到目前为止我们尝试了什么：
Thread.sleep之间的批量。
在查询级别删除缓存并将其从索引中删除。
在不同（较慢）的硬件上尝试相同的索引。
确认它不是竞争条件（在我们的代码中）。
更新
the query喜欢什么。
搜索线程池：
"search" : {
"type" : "fixed",
"min" : 4,
"max" : 4,
"queue_size" : 1000
},
第二次更新：
我们还尝试设置我们的查询首选项（认为它是分片的问题）：.preference(Preference.Primary)没有正面结果（它们比以前更加随机）。使用此设置连续两次运行会给出不同的＆＃34;随机＆＃34;结果，所以这不一致。