如何诊断ElasticSearch搜索队列增长

Question

我试图诊断我们的ElasticSearch搜索队列似乎随机填满的问题。

我们在监视器中观察到的行为是，在我们集群的一个节点上，搜索队列增长（只有一个），在搜索线程池用完之后，我们开始获得超时。似乎有一个查询阻止了这件事。我们目前解决问题的唯一方法是重新启动节点。

您可以在下面看到图表中的相关行为：首先是队列大小，然后是待处理的集群任务（以显示没有其他操作阻塞或排队，例如索引操作等），最后是搜索的活动线程线程池。 11点钟的尖峰是节点的重启。

在我们重新启动节点之前，所有节点上的日志文件在问题发生之前或之后的一小时内都没有显示任何条目。只有大约200到600毫秒的垃圾收集事件，相关节点上只有一个垃圾收集事件，但事件发生前约20分钟。

我的问题： - 我如何调试它，因为在失败或超时查询的任何地方都没有记录信息？ - 这有什么可能的原因？我们没有动态查询或类似的东西 - 当发生这种情况时，我可以设置查询超时或清除/重置活动搜索以阻止节点重启吗？

根据迄今为止的问题，还有一些不适用的细节：

• 完全相同的硬件（16核，60GB内存）
• 相同的配置，没有特殊节点
• 未启用交换
• 在IO或CPU
等其他指标上没什么值得注意的
• 不是主节点
• 没有特殊的分片，每个节点每个节点有三个分片，有条件的标准查询，以前发送到ES 10分钟的所有查询都是通常在5-10ms内完成的查询，我们得到超时的所有查询都是相同的，没有提高查询率或其他任何内容
• 我们有5个节点用于此部署，所有节点都是循环访问
• 我们在信息级别上有2秒的慢速日志，没有条目

队列建立1分钟后的热线程处于https://gist.github.com/elm-/5ed398054ea6b46522c0，一些转储的几个快照片刻。

Answer 1

这是一次非常开放式的调查，因为可能存在许多错误。流氓查询可能是最明显的原因，但问题是其他节点不受影响的原因。我认为最相关的线索是，为什么这个节点如此特殊。

要看的事情：

• 比较节点之间的硬件规格
• 比较配置设置。看看这个节点是否与众不同。
• 如果启用了交换，请查看所有节点上的交换。检查mlockall，看看它是否设置为true。
监控工具中的
• 将队列大小与其他内容相关联：内存使用率，CPU使用率，磁盘IOPS，GC，索引率，搜索率
• 当该队列填满时，该节点是主节点吗？
• 查看分片分配：是否有任何＆＃34;特殊＆＃34;这个节点上的碎片突出了吗？将其与您通常运行的查询相关联。也许路由在这里发挥作用。
• 您是将查询发送到同一节点，还是对所有节点执行循环查询
• 尝试启用慢速日志并降低阈值并尝试捕获所谓的有问题的查询（如果有的话）

Answer 2

Andrei Stefan的回答并没有错，但我首先要看看来自堵塞节点的hot_threads，而不是试图弄清楚节点可能有什么特别之处。

我不知道你在队列中查看的方法。像安德烈说的那样，慢速日志是一个好主意。