搜索响应时间不规律地翻了一番

Question

我们的系统最近遇到了 CPU 使用率高峰，其根本原因仍然未知。过去，我们面临着高内存使用和磁盘警报，因为我们每晚都运行批量索引工作，更新几乎所有文档。但是高 CPU 使用率并不是问题。

目前收集的数据：

节点 03（6 个数据节点和 3 个主节点）遭受高 CPU 使用率 (> 95%) 5 分钟，导致响应时间峰值为 1 秒，而平均响应时间为 40 毫秒。 查看指标，在给定的高 CPU 节点上的索引计数略有增加，同时 Young GC 也有轻微的增加（但在这两种情况下都不像峰值）。

我不排除大量索引，因为我们确实有一个 kafka 消费者随时接受批量索引数据，但这控制在每秒最多 250 个文档的速度下，每个批量之间的延迟时间为 250 毫秒打电话。

此外，热线程端点确实提供了一些数据，虽然我还不能破译它。

Hot threads

更新

更新了问题标题，因为之前的观察结果是错误的。主要问题是响应时间加倍，并且 CPU 使用率不高，因为一段时间后使用率趋于稳定。

已经有了一些发展。峰值后，CPU使用率逐渐下降，属于正常现象。 但是，我们的响应时间始终保持在 100-250 毫秒之间（通常的平均值 - 35-100 毫秒）。

目前的响应中有一个接近锯齿形（不完全是一个均匀的锯齿形）模式。

此外，当峰值发生时，旧 GC 计数有一个小波动。

在节点统计中没有发现任何异常。找到后会更新。仍在发帖等待调查。

node stats

同时发布最近的热点话题-

hot_thread_2

Answer 1

Node 03 显然似乎经历了繁重的索引。

                "bulk": {
                "threads": 8,
                "queue": 0,
                "active": 0,
                "rejected": 0,
                "largest": 8,
                "completed": 9528532

我比较了节点 04 和节点 03 的统计数据。我在 03 上注意到的其他一些事情。

• 4144165 文档但 256087749 (index_total) 索引请求？
• 只有节点 03 有 41 个 open_contexts。因此，在您获取此统计信息时，它有 41 个搜索请求。其他所有节点均为 0。
• 与其他节点相比，节点 03 和节点 01 的合并次数非常多。

您是否有任何将特定文档发送到特定节点的路由逻辑？或者这些节点可能包含更新更频繁的索引？

当您看到峰值时，您或您的应用程序是否有机会对节点 03 上的索引进行优化？查看节点统计信息，03 是唯一具有“已完成”优化的节点

"optimize": {
                "threads": 1,
                "queue": 0,
                "active": 0,
                "rejected": 0,
                "largest": 1,
                "completed": 1
            },

另外，你的 refresh_interval 是多少？ ES 中的默认值为 1 秒。这可能会在批量索引时触发大量合并。