Elasitcsearch CPU 使用率突然飙升，怎么办？

2、Elasticsearch 高CPU 使用率的内涵

线上环境 Elasticsearch CPU 使用率飙升常见问题如下：

——来自《死磕Elasticsearch 知识星球》

Elasticsearch 使用线程池来管理并发操作的 CPU 资源。

关于线程池和队列，推荐阅读： Elasticsearch 线程池和队列问题，请先看这一篇。

Elasticsearch 高 CPU 使用率通常意味着一个或多个线程池不足以支撑业务需求。

如果线程池资源耗尽，Elasticsearch 将拒绝与线程池相关的请求。

例如，如果搜索线程池（search thread pool）耗尽，Elasticsearch 将拒绝搜索请求，直到有更多线程可用。

上图更直观的解释了线程池、队列、客户端请求之间的关系，拿检索线程为例：

当请求比较少时，线程池完全可以处理过来；
当前再多一些时，需要线程池队列排队；
如果请求再多，就超出了线程池和队列的最大负载，导致 异常报错 。

3、诊断 Elasticsearch 高 CPU 使用率

3.1 核查 CPU 使用率

使用 cat nodes API 获取每个节点的当前 CPU 使用率。

GET _cat/nodes?v=true&s=cpu:desc

返回结果：

如上所示，CPU 即为 cpu 使用率， name 为节点的名称。

也可以借助 Kibana Stack Monitoring 进行可视化监控，CPU 监控如下红圈所示：

3.2 核查热点线程

如果某个节点的 CPU 使用率很高，请使用节点热点线程 API 检查该节点上运行的资源密集型线程。

GET _nodes/my-node,my-other-node/hot_threads

此 API 以纯文本形式返回任何热点线程的细节。

4、降低 CPU 使用率的实操方案

以下 Tips 概述了 CPU 使用率高的最常见原因及其解决方案。

4.1 扩展集群

繁重的数据写入（indexing）和搜索负载会耗尽较小的线程池。
为了更好地处理繁重的工作负载，向集群添加更多节点或升级（扩容）现有节点以增加容量。

4.2 分散批量请求

批量请求虽然比单个请求效率更高，但大型批量写入或多搜索请求需要大量 CPU 资源。

如果可能，提交较小的请求并在它们之间留出更多时间。

这里的较小有多小？需要结合业务实际、结合线程池和队列大小不断调出最优值。

4.3 取消长时间运行的搜索

长时间运行的搜索会阻塞搜索线程池中的线程。

要检查这些搜索，请使用任务管理 API。

GET _tasks?actions=*search&detailed

上述命令行响应的描述包含检索请求及其查询细节，其中：running_time_in_nanos 显示搜索运行了多长时间。

"nodes" : { "oTUltX4IQMOUUVeiohTt8A" : { "name" : "my-node", "transport_address" : "127.0.0.1:9300", "host" : "127.0.0.1", "ip" : "127.0.0.1:9300", "tasks" : { "oTUltX4IQMOUUVeiohTt8A:464" : { "node" : "oTUltX4IQMOUUVeiohTt8A", "id" : 464, "type" : "transport", "action" : "indices:data/read/search", "description" : "indices[my-index], search_type[QUERY_THEN_FETCH], source[{\"query\":...}]", "start_time_in_millis" : 4081771730000, "running_time_in_nanos" : 13991383, "cancellable" : true

可以使用 _cancel API 取消任务以释放资源：

POST _tasks/oTUltX4IQMOUUVeiohTt8A:464/_cancel

4.4 避免耗费资源的搜索

举例：前缀匹配的 wildcard 查询、多重聚合或分桶设置过大的单重聚合都会非常耗费资源。

避免策略包含但不限于：

避免脚本 script 检索。
少使用： fuzzy 、 regexp 、 prefix 、 wildcard 检索
避免将 range 检索应用到 text 和 keyword 类型。
避免多表关联 Join 类型。
使用 index.max_result_window 索引设置降低大小限制。
使用 search.max_buckets 集群设置降低允许的聚合桶的最大数量。
使用 search.allow_expensive_queries 集群设置禁用耗费资源的查询。

建议提前做好集群监控和指标预警工作，“防范于未然”，结合节点的 CPU 核数最大化的提升线程池和队列的使用率。

你在实战环节有没有遇到高 CPU 利用率问题？你是如何解决的呢？欢迎留言交流细节。

和你一起，死磕 Elasticsearch！

1. https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html#query-dsl-allow-expensive-queries

2. https://www.elastic.co/guide/en/elasticsearch/reference/current/fix-common-cluster-issues.html#avoid-expensive-searches

3. https://www.elastic.co/guide/en/elasticsearch/reference/current/fix-common-cluster-issues.html 4. https://qbox.io/blog/thread-pools-elasticsearch-search-request-errors/

1 、重磅 | 死磕 Elasticsearch 方法论认知清单（2021年国庆更新版）

2 、 Elasticsearch 7.X 进阶实战私训课（口碑不错）

3、如何系统的学习 Elasticsearch ？

4、 Elasticsearch 磁盘使用率超过警戒水位线，怎么办？

更短时间更快习得更多干货！

已带领88位球友通过 Elastic 官方认证！

比同事抢先一步学习进阶干货！

Linux系统参数配置 Linux中，每个进程默认打开的最大文件句柄数是 100 0,对于服务器进程来说，显然太小，通过修改/etc/security/limits.conf来增大打开最大句柄数 * - ... Elasticsearch 使用线程池管理 CPU 资源，用于并发操作。如果某个节点的 CPU 使用率 很高，可以使用该节点的热线程API（hot_threads）来检查节点上运行的资源密集型线程。如图所示，查询请求量的波动与集群最大 CPU 使用率 是基本吻合的。确保对于节点上已配置的每个 GB的内存，将分片数量保持在 20 以下，如果某个节点拥有 30GB 的堆内存，那其最多可有 600 个分片。查看查询/写请求量，分析是否 cpu 高和查询量升高或者写入量升高导致的。是操作系统层面的 cpu 消耗，不是我们重点优化对象。大家好，我是飘渺。上次面试官问了个问题：应用上线后 Cpu 使用率 飙升如何排查？其实这是个很常见的问题，也非常简单，那既然如此我为什么还要写呢？因为上次回答的时候我忘记将线程PID转换成16进制的命令了。所以我决定再重温一遍这个问题，当然贴心的我还给大家准备好了测试代码，大家可以实际操作一下，这样下次就不会忘记了。模拟一个高 CPU 场景publicclassHigh Cpu T... 一个 Elasticsearch 集群至少包括一个节点和一个索引。或者它可能有一百个数据节点、三个单独的主节点，以及一小打客户端节点——这些共同操作一千个索引（以及上万个分片）。不管集群扩展到多大规模，你都会想要一个快速获取集群状态的途径。API 充当的就是这个角色。你可以把它想象成是在一万英尺的高度鸟瞰集群。它可以告诉你安心吧一切都好，或者警告你集群某个地方有问题。 ES PAAS管理的集群升级了 100 +，从7.5升级到7.17 （保证每个大版本最终仅维护一个小版本集群），由于业务使用差异大，也出了不少问题，前面的文章也有提到过Integer类型字段使用terms查询效率低的情况... 首先要阐述一个观点，任何技术都是为解决某一个领域的问题而存在的，我们在使用它的时候，尽可能使用它的优势（亮点），去发挥它应具备的业务价值。 es 在很多公司应用非常广泛，它已经成为玩大数据的必备的技能，在之前的章节我吐槽过 es 写方面的问题，今天将吐槽下 es 查询-terms语法的那些坑，这里探讨两点：一个是多terms并发带来高 CPU ，另一个是terms使用不当会导致bug。我们基于门店...