Question

我们的系统最近遇到CPU使用率飙升，其根本原因尚不清楚。我们过去曾面临过高内存使用和磁盘警报，因为我们每晚都会运行批量索引，几乎更新所有文档。但高CPU使用率并不是问题。

目前收集的数据：

节点03（6个数据节点中的3个和3个主节点）遭受高CPU使用率（> 95％）持续5分钟，导致响应时间峰值为1秒，而平均响应时间为40ms。在查看指标时，给定的高CPU节点上的索引计数略有增加，同时，Young GC略有增加（在这两种情况下都没有像尖峰一样）。

我不排除重型索引，因为我们确实有kafka消费者在任何时候都接受批量索引数据，但是控制速度最高为每秒250个文档，每个批量之间的滞后时间为250毫秒调用

此外，热线程端点确实提供了一些数据，但我还无法解读它。

Hot threads

更新

更新了问题标题，因为以前的观察结果是错误的。主要关注的是响应时间加倍而CPU使用率不高，因为一段时间后使用率已经稳定。

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

目前的回应中有一种近齿（不完全是均匀的齿锯）模式。

此外，当尖峰发生时，旧GC计数出现小幅下降。

在节点统计信息中未发现任何异常。找到后会更新。仍在调查。

node stats

同时发布最近的热线 -

hot_thread_2

Answer 1

节点03肯定似乎经历了重度索引。

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

我将Node 04的统计数据与Node 03进行了比较。我在03年注意到了一些其他的事情。

4144165 docs但256087749（index_total）索引请求？
只有Node 03有41个open_contexts。因此，在您获取此统计信息时，它有41个搜索请求。所有其他节点都是0.
与其他节点相比，节点03和节点01的合并次数非常高。

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

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

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

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

搜索响应时间不规律地加倍

1 个答案: