java - 如何诊断 ElasticSearch 搜索队列增长

Question

我正在尝试诊断我们的 ElasticSearch 搜索队列看似随机填满的问题。

我们在监视器中观察到的行为是，在我们集群的一个节点上，搜索队列增长(只有一个)，在搜索线程池用完后，我们当然开始超时。似乎有一个查询阻止了 while 事情。目前解决问题的唯一办法就是重启节点。

您可以在下面的图表中看到相关行为:首先是队列大小，然后是挂起的集群任务(以表明没有其他操作正在阻塞或排队，例如索引操作等)，最后是用于搜索的 Activity 线程线程池。 11点钟的尖峰是节点的重启。

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

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

一些不适用的详细信息，基于目前的问题:

• 完全相同的硬件(16 核，60GB 内存)
• 相同的配置，没有特殊的节点
• 未启用交换
• 在 IO 或 CPU 等其他指标上没有明显变化
• 不是主节点
• 没有特殊的分片，每个节点每个节点三个分片，pertty 标准查询，所有在 10 分钟前发送到 ES 的查询通常在 5-10 毫秒内完成的查询，我们超时的所有查询都是相同的，没有增加查询率或其他任何东西
• 我们有 5 个节点用于此部署，所有访问循环
• 我们在信息级别有 2 秒的慢日志，没有条目

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

Answer 1

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

要看的东西:

• 比较节点之间的硬件规范
• 比较配置设置。看看这个节点是否以不同的方式脱颖而出。
• 查看所有节点上的交换(如果交换已启用)。检查 mlockall 以查看它是否设置为 true。
• 在您的监控工具中将队列大小的增加与其他因素相关联:内存使用率、CPU 使用率、磁盘 IOPS、GC、索引率、搜索率
• 当队列填满时，这个节点是主节点吗？
• 查看分片分布:此节点上是否有任何“特殊”分片脱颖而出？将其与您通常运行的查询相关联。也许路由在这里发挥作用。
• 您是将查询发送到同一个节点，还是对所有节点执行循环查询
• 尝试启用慢速日志并降低阈值并 try catch 据称有问题的查询(如果有的话)